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rORD 


The  U.S.  Army  Research  Institute  for  the  Behavioral  and 
Social  Sciences  XARI} "is  conducting  a  program  to  develop  MANPRINT 
methods  to  successfully  integrate  Army  personnel  with  weapon  sys¬ 
tem  hardware  and  software.  As  the  first  stage  of  this  process, 
ARI  defined  requirements  for  six  classes  of  methods  and  called 
for  the  development  of  alternative  concepts  for  each  class. 

This  monograph  describes  three  alternative  concepts  for 
building  a  method  to  predict  required  operator  and  maintainer 
crew  sizes  for  a  system.  The  resulting  crew  sizes  can  be  used  to 
evaluate  the  manpower  implications  of  a  weapon  system  design  and 
can  serve  as  the  basis  of  a  cost-benefit  analysis.  These  con¬ 
cepts  will  serve  as  the  focus  of  current  system  building  and  may 
serve  as  a  seedbed  for  the  development  of  alternative  systems. 
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EDGAR  M.  JOHNSON 
Technical  Director 
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MANPRINT  METHODS  MONOGRAPH:  AIDING  THE  DEVELOPMENT  OF  MANPOWER- 
BASED  SYSTEM  EVALUATION 


EXECUTIVE  SUMMARY 


The  U.S.  Army  Research  Institute  for  the  Behavioral  and 
Social  Sciences  (ARI)  is  conducting  a  program  to  develop  methods 
to  successfully  integrate  operations  and  maintenance  personnel 
with  weapon  system  hardware  and  software  during  the  MANPRINT 
process.  To  do  this,  ARI  defined  requirements  for  six  classes  of 
methods.  In  the  first  phase  of  this  effort,  three  alternative 
concepts  were  developed  for  each  of  the  six  classes  of  methods. 

This  monograph  consists  of  three  papers  that  describe 
alternative  concepts  for  determining  the  operations  and  mainte¬ 
nance  manpower  required  by  a  weapon  system  design  on  a  per  system 
basis. 

Ultimately,  the  ARI  study  advisory  group  selected  the 
concept  proposed  by  MicroAnalysis  &  Design  for  implementation. 
However,  each  of  the  three  concepts  is  the  result  of  serious 
thinking  about  how  to  deal  with  manpower  prediction.  As  such, 
all  three  concept  papers  may  be  of  considerable  value  for  re¬ 
search  in  this  area. 
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MANPRINT  METHODS  MONOGRAPH:  AIDING  THE 
DEVELOPMENT  OF  MANPOWER-BASED  SYSTEM  EVALUATION 


Introduction 


The  U.S.  Army  Research  Institute  (ARI)  is  conducting  a 
research  program  to  develop  methods  to  aid  in  successfully 
integrating  available  operations  and  maintenance  personnel 
with  hardware  and  software  as  part  of  the  general  MANPRINT 
process.  To  do  this,  ARI  defined  and  produced  requirements 
for  six  classes  of  aiding  methods.  The  first  four  of  these 
methods  will  aid  the  integration  process  by  developing 
information  that  will  be  used  as  system  design  constraints. 
This  information  will  be  used  in  requirements  documents  and 
will  be  provided  to  potential  design  organizations.  The 
last  two  of  these  methods  will  aid  the  integration  process 
by  providing  mechanisms  to  evaluate  system  designs. 

This  monograph  consists  of  three  papers  on  a  common 
subject:  How  to  determine  the  number  of  soldiers  per  system 

required  by  a  design  to  reach  criterion  performance  and 
availability.  Each  of  these  three  papers  presents  a  concept 
for  building  an  aiding  method  for  making  these  predictions. 
These  methods  would  all  be  software  based  and  provide  aid 
without  significantly  raising  their  user’s  workload.  All 
concepts  were  generated  in  response  to  the  same  Army 
requirement.  To  understand  these  concepts  fully,  one  must 
first  understand  the  context  in  which  they  were  developed. 

The  Army  acquires  systems  as  mechanisms  for  obtaining 
needed  performance.  The  hardware  and  software  components  of 
most  Army  systems  are  operated  and  maintained  by  soldiers. 
Therefore,  soldiers  are  components  of  those  systems.  The 
performance  and  availability  levels  of  systems  are  directly 
related  to  the  performance  of  the  trained  soldiers  who 
operate,  maintain,  and  support  their  hardware  and  software. 

The  decision  to  move  from  system  design  to  prototype 
hardware  and  software  is  a  major  one  that  commits  the  Army 
to  considerable  expense  and  eventually  to  battlefield  risk. 
The  hardware  and  software  development  community  has 
demonstrated  the  ability  to  produce  products  that,  in 
theory,  are  capable  of  very  high  levels  of  performance  and 
system  availability.  The  key  words  here  are  "in  theory." 

In  practice,  these  high  levels  are  not  often  produced  by 
operational  Army  personnel,  although  they  are  demonstrated 
by  the  development  community.  This  gap  between  theoretical 
and  operational  performance  and  system  availability  often 
occurs  because  it  is  difficult  for  the  Army  to  obtain 
adequate  numbers  of  personnel  who,  following  typical 
training,  are  capable  of  operating  and  maintaining  equipment 
of  suboptimal  design  to  required  levels.  This  being  the 
case,  the  Army  needs  to  be  able  to  determine  the  numbers  and 
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kinds  of  personnel  required  by  design  features  to  reach 
criterion  performance  and  system  availability  prior  to 
deciding  to  move  from  an  existing  initial  design  to  the 
building  of  a  prototype.  The  determination  of  the 
availability  of  the  required  numbers  and  kinds  of  personnel 
will  allow  the  Army  to  engage  in  a  rational  evaluation  of 
system  designs. 

The  purpose  of  this  specific  aiding  method  is  to 
evaluate  designs  by  determining  the  jobs  and  the  number  of 
people  per  job  required  to  operate  and  maintain  the  hardware 
and  software  as  designed,  so  that  the  Army  has  a  basis  to 
determine  manpower  requirements  and  compare  that  to  manpower 
availability.  Jobs  are  defined  as  that  cluster  of  described 
tasks  which  are  to  be  performed  by  one  individual  in 
operating  or  maintaining  system  hardware. 

The  three  concepts  for  this  manpower-based  evaluation 
aid  were  written  by  a  col laborat i on  of  Micro  Anal ys i s  k 
Design  (MA&D)  and  the  Dynamics  Research  Corporation  ( DRC ) , 
Science  Applications  International  Corporation  (SAIC)  acting 
as  a  subcontractor  to  Applied  Science  Associates  (ASA),  and 
a  collaboration  of  Hay  Systems,  Inc.  and  Percept,  ron  i  cs  Inc. 
Eventually,  ARI  chose  to  complete  the  development  of  MA&D’s 
concept.  However,  all  three  concepts  have  considerable  merit 
and  are  quite  diverse  in  approach. 

The  MAVD-DRC  concept  requires  the  development  of  three, 
simulation-based  methods  in  one  shell.  One  method 
determines  the  number  of  maintainers  required  to  reach 
criterion  sytem  availability  by  simulating  hardware 
breakdowns  and  maintenance  task  performance  at  the  component 
level.  The  second  and  third  methods  attempt  to  determine 
the  'squired  number'  of  operators  or  maintainers  assuming 
either  that  the  design  can  be  altered  to  introduce 
additional  personnel,  or  that  workload  can  be  optimized 
among  a  fixed  number  of  personnel  by  reallocating  tasks. 

The  second  method  uses  a  simulation  to  compare  time 
available  to  time  required  for  each  task  of  each  job.  The 
third  method  links  a  cognitive  workload  model  to  the  time 
required  model  to  provide  a  more  detailed  basis  for  creating 
new  jobs  or  optimizing  workload  among  existing  jobs. 

The  SAIC  concept  is  based  upon  providing  a  two-step 
task-clustering,  precedence-network  analysis  aid.  In  the 
first  of  two  steps,  operator  or  maintainer  tasks  are 
clustered  based  on  their  association  with  syst  em  performance 
objectives  that  have  been  entered  by  the  user.  In  the 
second  step,  unique  jobs  are  created  based  on  task  clusters, 
sequences  and  times  plus  any  job  constraints  entered  by  the 
user.  These  jobs  fall  into  the  categories  of  time-based, 
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out  put -based ,  and  continuous  monitoring-based.  In  genera], 
the  method  attempts  to  create  or  optimize  jobs  by 
reallocating  those  tasks  that  can  be  performed  in  the  least 
period  of  time. 

The  Hay-Perceptron i cs  concept  fundamentally  is  based 
upon  clustering  tasks  into  jobs  according  to  a  combination 
measure  of  their  similarities  and  utilities  (S/U).  This  is 
done  within  the  context  of  a  set  of  rules  that  determine  the 
possibility  of  task  performance  for  a  given  job  using  a 
given  interface  design.  The  S/T  measure  discussed  in  this 
approach  is  "competency."  It  is  determined  by  comparing 
measures  of  the  basic  skills  and  capabilities  that  personnel 
must  posses  to  perform  tasks,  and  is  derived  from  training 
data.  Once  tasks  are  clustered,  the  resulting  jobs  will  be 
tested  for  workload  using  some  form  of  network  simulation. 

As  with  all  apparently  simple  ideas,  complexity 
increases  as  one  tries  to  visualize  implementation.  This 
can  be  seen  in  t  lie  necessity  to  answer  the  following  two 
quest  ions  in  any  concept  for  evaluating  designs  on  a 
manpower  basis.  (1 )  How  would  a  manpower  based  evaluat ion 
aid  dea i  with  crew  size  prediction  for  operations  versus 
maintenance  crews'.'  (2)  How  would  such  an  evaluation  aid 
deal  with  designs  in  which  crew  size  it.  a  function  of 
spe  ific  interface  design  versus  somewhat  arbitrary  function 
al  lea:  ion?  Inherent  in  the  first  question  is  the  issue  of 
whether-  individual  maintenance  task  design  should  be 
optimized  in  the  same  manner  as  is  typically  given  to 
operations  tasks.  Inherent  in  t  lie  second  question  is  the 
issue  of  how  to  do  a  manpower-based  analysis  of  a  system  in 
which  the  interface  hardware  design  has  been  made  for  a 
specified  number  of  people.  The  concepts  presented  here 
wrestle  with  such  coni}.  1  ex  i  t  y  with  varying  degrees  of 
success  .  However-,  mu<h  is  to  be  gained  in  the  exercise  and 
it,  the  competition  of  ideas. 

The  three  concept  papers  in  this  monograph  have  been 
paginated  as  l.  i  ,  1.2,  and  1?  to  delineate  t  ic-m  clear.  >. 
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SECTION  1  -  INTRODUCTION 


1.1  Objective  of  Paper 

This  concept  paper  describes  the  Micro  Analysis  and  Design 
and  Dynamic  Research  Corporation  team's  approach  to  the 
development  of  a  Manpower  Determination  Aid  (MDA) .  The  purpose 
of  the  MDA  will  be  to  provide  Army  manpower  analysts  with  a  tool 
for  evaluating  manpower  requirements  for  a  given  contractor 
design.  There  are  three  primary  things  that  the  MDA  will 
produce,  1)  job  titles  and  descriptions,  2)  allocations  of  tasks 
to  jobs,  and  3)  the  numbers  of  individuals  for  each  job  type 
required  to  support  one  system  (e.g.,  a  tank). 


1.2  Overview  of  the  Approach 

We  have  split  the  MDA  into  two  fairly  distinct  components, 
one  for  predicting  manpower  requirements  for  operators  of  systems 
and  one  for  predicting  manpower  requirements  for  maintainers  of 
systems.  Both  work  in  a  conceptually  similar  manner,  althouqh 
the  details  of  using  each  component  are  different.  In  fact,  the 
operator  prediction  tool  could  also  be  applied  to  maintainers, 
however;  in  our  concept  we  have  chosen  a  simpler  tool  for  the 
maintainer  prediction  tool. 

Both  operator  and  maintainer  components  require  the 
development  of  a  list  of  tasks  which  must  be  performed  as  well  as 
relationships  between  frequency  of  task  performance  and  specific 
mission  scenarios.  Then,  based  on  a  variety  of  potential 
starting  points,  operator  and  maintainer  jobs  are  initially 
defined  and  tasks  are  allocated  to  these  operator  and  maintainer 
jobs.  This  initial  allocation  of  tasks  to  operators  and 
maintainers  represents  the  first  "hypothesis”  about  how  tasks 
should  be  allocated  to  jobs.  Then,  this  hypothesis  is  tested 
against  three  types  of  constraints,  1)  a  workload  constraint 
(i.e.,  can  the  operators  and  maintainers  perform  the  tasks  in  the 
allotted  time  and  still  maintain  a  reasonable  level  of 
workload?),  2)  performance  constraints  (i.e.,  can  the  operators 
meet  system  performance  requirements  and  can  maintainers  meet 
system  availability  requirements?),  and  3)  supportability 
constraints  (i.e.,  can  the  system  design  support  the  number  of 
operators  and  maintainers) . 

The  extent  to  which  a  given  task  allocation  to  jobs  will 
satisfy  workload  and  performance  constraints  are  explored  through 
the  use  of  computer  simulation.  The  heart  of  the  MDA  will  be  a 
set  of  tools  which  will  permit  rapid  development,  execution,  and 
analysis  of  computer  simulations  to  study  workload  and  system 
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performance.  The  proposed  concept  builds  off  of  existing  easy- 
to-use  simulation  tools.  The  computer  simulations  will  permit 
the  evaluation  of  the  extent  to  which  a  specific  contractor 
design  will  violate  either  workload  or  performance  constraints 
given  the  hypothesized  allocation  of  tasks  to  jobs. 

The  supportability  constraint  will  be  studied  in  a  more 
straightforward  manner.  It  will  involve  the  user  of  the  MDA  to 
review  a  series  of  questions  relating  to  the  allocation  of  tasks 
to  jobs  considering  the  specific  contractor  design. 

The  process  of  defining  an  acceptable  allocation  of  tasks  to 
jobs  and  the  associated  numbers  of  individuals  for  each  job  will 
be  one  of  1)  develop  a  hypothesis,  2)  using  the  MDA,  test  the 
hypothesis,  and  3)  if  it  does  not  satisfy  all  constraints, 
reallocate  tasks  to  jobs  or  change  the  number  and  type  of  jobs, 
and  4)  test  this  "new”  hypothesis.  Of  course,  the  MDA  will 
provide  a  number  of  diagnostic  tools  to  assist  the  user  of  the 
MDA  in  identifying  "better"  allocations  of  tasks  to  jobs.  The 
user  of  the  MDA  will  proceed  through  this  hypothesis  testing 
process  until  either  an  alternative  is  found  that  satisfies  all 
constraints  or  it  becomes  clear  that  no  such  alternative  exists. 

Tha  workload  portion  of  the  MDA,  which  is  used  to  predict  the 
operator's  jobs,  also  considers  another  type  of  constraint,  the 
accessability  constraint.  In  other  words,  the  tool  will  aid  the 
analyst  in  ensuring  that  no  tasks  are  allocated  to  operators  that 
involve  controls  or  displays  that  he  cannot  reach  or  see. 

The  overall  maintenance  requirements  are  determined  by 
computer  simulation.  Embedded  in  the  maintenance  component  of 
the  MDA  will  be  a  simulation  model  that  will  use  Monte  Carlo 
simulation  techniques  to  aggregate  the  maintenance  manpower 
requirements  based  on  the  maintenance  requirements  of  the 
individual  components. 

The  software  that  will  be  included  in  the  maintenance 
component  of  the  MDA  will  guide  the  analyst  through  the  process 
of  identifying  and  entering  the  tasks  required  to  maintain  each 
component  in  the  proposed  system,  how  frequently  each  task  needs 
to  be  performed,  and  what  kinds  of  maintainers  are  needed  to 
perform  those  tasks.  The  software  will  also  assist  the  Army 
analyst  in  defining  mission  scenarios  that  will  determine  1)  the 
usage  rates  for  each  component,  and  2)  the  amount  of  time  that  is 
available  for  maintenance  in  different  mission  scenarios  given 
system  availability  requirements. 

The  computer  simulation  model  that  is  embedded  within  the 
maintenance  component  of  the  MDA  will  use  the  component 
maintenance  requirements,  usage  rates,  and  the  time  that  is 
allotted  for  maintenance  during  the  simulation  period  to  simulate 
the  overall  maintenance  requirements  of  the  proposed  new  system. 
The  results  of  the  simulation  will  give  the  Army  analyst  an 
indication  of  the  different  maintenance  jobs  that  were  required 
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during  the  analysis  period,  the  tasks  that  were  assigned  to  each 
maintenance  job,  the  number  of  hours  of  maintenance  that  were 
required  for  each  maintenance  job,  and  the  actual  number  of 
people  that  were  required  to  maintain  system  availability  for 
mission  requirements  and  the  percentage  of  time  that  number  were 
needed. 

Virtually  the  entire  process  of  using  the  MDA  will  be 
automated.  When  using  the  MDA  to  define  jobs,  tasks  per  job,  and 
numbers  per  job,  the  user  will  be  provided  with  menus  for  filling 
in  the  necessary  information.  Also,  a  key  part  of  the  MDA  will 
be  a  series  of  on-line  libraries  available  to  the  user.  In  these 
libraries  will  be  data  on  existing  systems  which  the  analyst  may 
draw  upon  to  establish  initial  job  definitions,  task  analyses, 
task  assignments  to  jobs,  and  task  performance  parameters 
required  for  the  simulation.  Additionally,  there  will  be 
specific  software  to  aid  the  user  in  the  development  of  the  above 
information  should  none  of  the  data  in  the  library  be 
appropriate. 

The  underlying  analytical  techniques  for  both  the  operator 
and  maintainer  portions  of  the  MDA  are  tried  and  tested. 

However,  the  MDA  tools  which  are  discussed  in  this  paper  will 
differ  in  that  they  will  be  orders  of  magnitude  easier  and  faster 
to  use  than  current  tools.  Furthermore,  the  Hpieces"of  the  MDA 
have  already  been  tested  in  other  military  environments  by  the 
authors  of  this  paper.  For  the  aforementioned  reasons,  it  is 
safe  to  say  that  there  is  neither  technical  nor  cost  risk  with 
the  approach  presented  herein. 

The  approach  to  an  MDA  presented  in  this  paper  represents  a 
practical,  logically-based,  quantitative  approach  to  directly 
evaluating  a  system  design  with  respect  to  the  manpower  required 
to  operate  and  maintain  that  proposed  system. 


1.3  Organization  of  Paper 

The  remainder  of  this  concept  paper  is  organized  into  five 
sections.  The  section  on  product  requirements  includes  the 
product's  objectives,  significant  output,  users,  role  in  the 
acquisition  process,  assumptions,  and  the  high-level  functional 
requirements  and  constraints  associated  with  it. 

The  next  two  sections  describe  the  two  modules  that  make  up 
the  MDA;  the  Workload  Assessment  Aid  (WAA)  and  the  Maintenance 
Manhour  Analysis  Aid.  Each  of  these  sections  is  organized  into 
three  sub-sections.  The  overview  of  each  section  discusses: 

•  the  theory  behind  the  approach  used  for  the  aid. 

•  the  approach  itself. 

•  the  outputs  of  the  aid. 
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•  the  automated  components  that  make-up  the  aid. 

•  the  approach  for  product  development. 

The  second  sub-section  for  each  of  the  two  modules  contains  a 
detailed  discussion  of  the  steps  that  an  Army  analyst  will  follow 
to  use  the  aid.  For  each  step  we  have  included: 

•  the  inputs  that  are  required. 

•  the  process  that  the  analyst  will  follow. 

•  the  outputs  of  the  step. 

•  a  discussion  of  user  interface  issues. 


The  third  sub-section  in  each  module  section  will  contain  a 
detailed  discussion  of  the  software  elements  that  are  included  in 
that  module. 

The  final  section  contains  references  that  are  used 
throughout  the  concept  paper. 
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SECTION  2  -  PRODUCT  REQUIREMENTS 


2.1  Objectives 

The  purpose  of  the  Manpower  Requirements  Determination  Aid 
(MDA)  is  to  determine  the  quantitative  manpower  requirements  for 
a  specific  contractor’s  design.  The  MDA  will  be  used  during  the 
Proof-of-Principle  Phase,  after  the  contractor  submits  the 
initial  designs,  but  before  one  design  is  chosen  to  develop  into 
a  prototype.  The  Manpower  Determination  Aid's  output  will  be 
used  with  the  output  from  Product  6.  The  combined  output  will 
help  develop  manpower,  personnel,  and  training  (MPT)  alternatives 
that  minimize  personnel  characteristics  deficits.  These  deficits 
are  discrepancies  between  the  type  and  number  of  people  required 
and  the  number  of  such  people  likely  to  be  available  when  the 
system  is  fielded. 


2.2  Manor  Output 

The  MDA  will  determine  manpower  requirements  for  each 
contractor  design.  These  requirements  will  include:  1)  the  jobs 
associated  with  each  design,  2)  the  tasks  associated  with  each 
job,  and  3)  the  number  of  operators  or  maintainers  in  each  job. 

In  addition  to  defining  manpower  requirements  by  job  or  duty 
position,  the  MDA  will  be  capable  of  assigning  each  job  to  an 
MOS,  and  calculating  total  manpower  requirements  by  military 
occupational  specialty  (MOS),  skill  level,  major  component  item 
(for  maintainers  only),  and  maintenance  level  (for  maintainers 
only)  . 

In  addition  to  producing  manpower  requirements  estimates,  the 
MDA  will  have  the  capability  to  estimate  system  availability, 
reliability,  and  operational  effectiveness.  We  will  compare 
these  estimates  with  the  requirements  that  the  System  Performance 
Requirements  Estimation  Aid  (Product  1)  identified  during  the 
Requirements  Technology  Base  Activities  Phase  of  the  Materiel 
Acquisition  Process  (MAP) .  This  comparison  can  identify  short¬ 
falls  (discrepancies  between  requirements  and  estimates  based  on 
contractor  design) . 


2.3  Role  of  Product  Output  in  Acquisition  Process 

During  the  acquisition  process,  manpower  requirements  for  an 
emerging  system  are  described  primarily  in  two  documents.  These 
documents  are  the  basis-of-issue  plan  (BOIP)  and  the  qualitative 
and  quantitative  personnel  requirements  information  (QQPRI) 
documents.  This  section  explains  how  these  documents  present 
quantitative  manpower  requirements,  where  the  information  comes 
from,  and  who  is  responsible  for  this  information. 
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The  MDA  will  be  designed  to  provide  input  to  these  two 
documents . 

BOIP 


The  BOIP: 

"States  the  number  of  new  or  improved  items  of  equipment 
and  personnel  to  be  included  in  Tables  of  Organization 
and  Equipment  (TOE)  Level  1  (100  percent  wartime 
requirements) ,  Tables  of  Distribution  and  Allowances 
(TDA) ,  Joint  Tables  of  Allowances  ( JTA) ,  Additive 
Operational  Projects  (AOP) ,  and  TDA  Augmentation  to 
Modified  Tables  of  Organization  and  Equipment  (MTOE)  when 
directed  by  HQDA . "  (Revised  AR  71-2,  Section  1-5) 

The  BOIP  must  justify  the  Manpower  requirements  it  includes  by 
clearly  stating: 

"The  rationale  considered  in  determining  the  type  and 
number  of  items  and  personnel  needed  to  support  the 
principal  item  (QQPRI,  operator  and  maintainer 
decision) .  Personnel  increases  exceeding  requirements 
document  estimates  will  be  justified  or  trade-off 
assessment  completed."  (Section  5-9) 

The  Deputy  Chief  of  Staff  for  Operations  and  Plans  (DCSOPS) 
is  the  Army  staff  proponent  for  the  BOIP  system. 


QQPRI 

The  revised  AR  71-2  describes: 

"The  QQPRI... [as]  a  compilation  of  organizational, 
doctrinal,  training,  duty  position,  and  personnel 
information.  It  is  prepared  for  a  new  or  improved  item 
of  equipment  by  the  materiel  developer  in  coordination 
with  the  combat  and  training  developer .. .The  QQPRI  is 
used  as  follows: 

(1)  To  determine  the  need  to  establish  or  revise 
a  Military  Occupational  Specialty  (MOS) , 
Specialty  Skill  Identifier  (SSI) ,  and 
civilian  OPMCS. 

(2)  To  prepare  plans  to  provide  the  personnel  and 
training  needed  to  operate,  maintain,  and 
transport  the  new  or  improved  item  of 
equipment. 

(3)  As  a  source  document  for  direct  productive 
annual  maintenance  manhours  (DPAMMH) . " 
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Figure  1  presents  the  QQPRI  format.  One  of  the  QQPRI* s  key 
components  is  the  DPAMMH: 

" [The]  DPAMMH  will  be  based  on  the  empirical  data  or, 
as  a  minimum,  estimated  hours  will  be  submitted  and  so 
identified  for  all  developmental  items  of  equipment  or 
system.  Hours  will  be  expressed  by  MOS,  SSI,  and  OPMCS 
for  each  category  of  maintenance.  When  LSA  data  or 
engineering  estimates  are  sources  for  DPAMMH,  the 
annual  usage  rate  used  in  the  computation  should  be 
provided.  This  annual  usage  rate  should  be  a 
derivative  of  equipment  mission  profile  found  in  the 
appropriate  materiel  need  document."  (Section  4.8) 

According  to  AR  71-2,  the  QQPRI  also  presents: 

"The  number  of  direct  operators  needed  to  make  up  a 
crew  or  operate  the  system  as  a  single  shift  and  a 
listing  of  duty  positions,  by  descriptive  title, 
required  for  operation  and  maintenance  of  the  equip¬ 
ment.  [It  also  contains]  a  suggested  placement  of  duty 
positions  within  a  current,  revised,  or  new  commis¬ 
sioned  officer  SSI,  or  warrant  officer  or  enlisted  MOS, 
special  qualification  identifier  (SQI) ,  ASI,  or 
civilian  OPMCS. 

A  listing  of  the  individual  system  unique  duties  and 
tasks  to  be  performed  in  each  of  the  above  identified 
positions  requiring  new,  revised,  or  current  MOS,  SSI 
and  OPMCS.  Other  special  characteristics  (e.g.,  a 
certain  height  to  operate  equipment,  a  security 
clearance  required  to  operate  or  maintain  the  equipment 
that  is  not  normally  required)  will  also  be 
identified."  (Section  4.8) 

As  the  QQPRI  format  presented  in  Figure  1  indicates, 
"Materiel  developers  will  identify  LIN,  nomenclature, 
description,  levels  of  maintenance  (UL,  IDS,  IGS,  AVIM,  AVUM) , 
MOS,  SSI,  and  civilian  OPMCS." 
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TITLE:  The  title  of  the  QQPRI  will  identify  the  type  of  QQPRI,  the  title  of  the  principal  item,  the  LIN,  PIP 
number,  and  the  new  equipment  training  plan  (NETP  number).  This  same  title  will  be  used  on  all 
correspondence  forwarding  the  QQPRI  through  channels.  Note:  Once  TRADOC  assigns  the  BOIP 
number,  the  numbers)  will  be  included  in  all  subsequent  correspondence. 

1 .  REQUIREMENT  INFORMATION: 

a.  Requirement  or  Procurement  Directive: 

b.  Type  Classification  (TC)  date: 

c.  First  Unit  Equipped  date  (FUED): 

d.  Army  Modernization  Information  Memorandum  (AMIM)  Number:  (Note  1) 

2.  DESCRIPTION  AND  DIRECT  PRODUCTIVE  ANNUAL  MAINTENANCE 
MANHOURS  (DPAMMH):  (Notes  2, 3, 4,  and  5) 

a.  Principal  Item: 

b.  Component  Major  Item: 

c.  Total  DPAMMH  by  MOS,  SSI,  or  OPMfcS  for  subparagraphs  a  and  b  above: 

d.  Associated  Support  Items  of  Equipment  (ASIOE): 

3.  NUMBER  DIRECT  OPERATORS  REQUIRED  TO  CREW  OR  OPERATE 
EQUIPMENT: 

4.  DUTY  POSITIONS  BY  DESCRIPTIVE  TITLE: 

5.  INDIVIDUAL  UNIQUE  DUTIES,  TASKS,  AND  CHARACTERISTICS:  (Notes  6  and  7) 

6  NETP  NUMBER  AND  NET  TRAINING  BASE  REQUIREMENTS:  (Notes  1  and  8) 

(Enclosures  -  Draft  Job  Specifications) 

Note  1.  Use  "NA"  for  paragraphs  id  and  6  when  not  applicable. 

Note  2.  The  format  subparagraphs  a  through  d  above  will  appear  on  all  QQPRI  This  format  is  very 
flexible  to  use  on  the  four  subparagraphs  (a-d)  or  can  be  expanded  by  using  "high  school  outline"  to 
accommodate  major  systems,  or  multiple  LIN  under  each  subparagraph  (a.  b,  and  d) 

Note  3.  Materiel  developers  will  identify  L!N,  nomenclature,  description,  levels  of  maintenance  (UL, 
IDS,  IGS,  AVIM,  AVUM),  MOS,  SSI,  and  civilian  OPMCS.  Materiel  developers  will  always  provide 
DPAMMH  for  the  principal  LIN  and  the  component  major  items  whether  they  are  type  classified  or  not 
Additionally,  the  materiel  developers  will  provide  DPAMMH  for  all  ASIOE  that  have  developmental 
items.  For  type  classified  ASIOE,  the  materiel  developer  will  list  the  LIN  and  nomenclature  only 
DPAMMH  will  be  based  on  the  empirical  data,  or  as  a  minimum,  estimates  will  be  submitted  and  so 
identified.  DPAMMH  should  represent  the  maintenance  burden  generated  by  one  item  ol  equipment 
during  one  year.  When  LSA  data  or  engineering  estimates  are  sources  for  DPAMMH.  the  annual 
usage  rate  used  in  the  computation  should  be  provided.  This  annual  usage  rate  should  be  derivation 
of  equipment  mission  profile  found  in  the  appropriate  materiel  need  document.  Usage  of  "Note"  to 
explain  information  or  rationale  is  encouraged. 

Note  4.  Formatting  for  each  LIN  under  the  subparagraph  a  and  b  including  the  type  of  equipment  is 
below.  MCI  will  be  subdivided  by  developmental  item(s)  and  type  classified  item(s);  show  NSN  or  PN 
for  aO  CMI. 


Figure  1.  QQPRI  Format 
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LIN,  Generic  Nomenclature,  Description  (for  TMDE  start  the  description  with  the  term  TMDE’  and 
include  Central  TMDE  Activity  (CTA)  approval  number) 

MQS/Sa/-CPMCS  iL  JDS.  rs 

Note  5.  Subparagraph  c  is  to  be  calculated  on  the  basis  of  one  principal  item  and  any  CM  I  in  required 
quantities.  Formatting  will  be: 

MOSZSaiQEMCS.  DPMM-f 

Note  6.  Paragraph  5  above: 

a.  Do  not  include  skills.  The  SGA  determines  the  skill  level. 

b.  Include  MOSs  that  support  the  maintenance  levels  of  ail  ASIOE. 

c.  For  aviation  equipment,  include  any  ground  maintenance  that  is  not  authorized  in 
AVUM/AVIM,  but  are  at  the  UL,  IDS,  and  IGS  level  of  maintenance. 

Note  7.  Paragraph  5  above: 

a.  If  the  duties  and  tasks  listed  in  AR  611-101,  AR  611-112,  or  AR  611-201  are  adequate,  use 
the  following  for  each  MOS  or  SSI: 

FOR  COMMISSIONED  OFFICERS: 

SSI. . .  (indicate  any  SOI  here)  performs  duties  and  tasks  as  listed  in  AR  61  i-iOi 
FOR  WARRANT  OFFICERS  OR  ENLISTED: 

MOS. . .  (indicate  any  ASI  or  SOI  here)  performs  duties  and  tasks  as  listed  in  (AR  61 1-1 12.  AR 
611-201). 

b.  If  the  duties  and  tasks  listed  in  AR  611-101,  AR  611-112.  AR  61 1-201  do  not  include  the 
system  unique  duties,  tasks,  or  characteristics,  use  the  following  for  each  MOS  and  SSI: 

FOR  COMMISSIONED  OFFICERS; 

SSI. . .  (indicate  any  SOI  here) _ (indicate  system  unique  duties,  tasks,  characteristics)  Other 

duties  and  tasks  are  listed  in  AR  611-101 . 

FOR  WARRANT  OFFICERS  OR  ENLISTED: 

MOS. . .  (indicate  any  ASI  or  SOI  here). , . .  (indicate  system  unique  duties,  tasks,  charactenstics). 
Other  duties  and  tasks  are  listed  in  (AR  611-112  or  AR  611-201). 

c.  If  the  duties  and  tasks  in  AR  611-101,  AR  611-112  or  AR  611-201  need  to  be  revised,  use  the 
following  for  each  MOS  and  SSI. 


Figure  1.  QQPRI  Format  (Continued) 
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FOR  COMMISSIONED  OFFICERS: 


Revised  SSI. . .  (indicate  any  current  or  new  SOI  here).  Draft  proposed  job  specifications  are 
attached  at  enclosure. . .  .  Other  duties  and  tasks  are  listed  in  AR  611-101. 


FOR  WARRANT  OFFICERS  OR  ENLISTED: 

Revised  MOS. . .  (indicate  any  current  or  new  ASI  or  SOI  here).  Draft  proposed  job  specifications 
are  attached  at  enclosure...  .  Other  duties  and  tasks  are  listed  in  (AR  611-112,  AR  611-201). 

d.  It  a  new  MOS,  SSI,  ASI.  or  SOI  will  be  required  for  AR  611-101,  AR  611-112,  or  AR  611-201, 
use  the  following  for  each  MOS  and  SSI: 

FOR  COMMISSIONED  OFFICERS: 

New  SSI. . .  (indicate  any  SSI  here).  Draft  proposed  job  specifications  are  attached  at  enclosure. 


FOR  WARRANT  OFFICERS  AND  ENLISTED: 

New  MOS. . .  (indicate  any  ASI  or  SQI  here).  Draft  proposed  job  specifications  are  attached  at 
enclosure. . .  . 

Note  8.  Provide  the  following  for  Paragraph  6: 

a.  NETP  number  (if  none,  so  state) 

b.  UIC,  quantity,  LIN,  nomenclature  and  justification  for  any  NET  Training  Base  requirements 


The  combat  developer  within  the  TRADOC  proponent  school  has 
primary  responsibility  for  developing  the  BOIP  and  QQPRI .  The 
Program  Manager  within  the  Army  Materiel  Command  (AMC) 
subordinate  command  provides  input  to  the  combat  developer. 

DCSOPS  processes  and  approves  both  the  BOIP  and  QQPRI. 

The  latest  version  of  AR  71-2  recognizes  that  the  Army 
HARDMAN  methodology,  as  the  Army's  current  manpower  determination 
aid,  feeds  the  BOIP  and  QQPRI  data.  But  AR  71-2  also  leaves  room 
for  additional  DCSPER-approved  methodologies: 

"The  results  of  hardware  vs.  manpower  (HARDMAN) 
methodology  or  an  approved  DCSPER  methodology  will 
provide  source  data  for  the  BOIP  and  QQPRI  process." 

(Revised  AR  71-2,  10  Oct.  1986,  p.  10) 

The  MDA  will  probably  become  one  of  the  additional 
methodologies  cited  in  AR  71-2.  By  systematically  assessing 
workload,  the  MDA  will  provide  more  accurate  estimates  of 
manpower  requirements,  particularly  operator  requirements. 


Manpower  Assessment  in  Support  of  Requirements  Documents 

The  Letter  of  Agreement  (LOA)  and  Required  Operational 
Capability  (ROC)  both  have  sections  that  require  reporting  the 
results  of  a  "manpower/ force  structure  assessment."  TRADOC/AMC 
PAM  70-2  describes  this  assessment  as  follows: 

"Manpower/Force  Structure  Assessment.  Estimate 
manpower  requirements  per  system,  using  unit,  and  total 
Army  by  component  (Active,  ARNG,  USAR) .  Identify 
manpower  savings  resulting  from  replaced  systems,  if 
any.  Include  a  statement  to  require  an  assessment  of 
alternatives  to  reduce  manpower  requirements  and  an 
assessment  of  force  structure  implications  resulting 
from  system  inclusion  in  the  total  force  by  component. 

If  the  force  structure  assessment  exceeds  current 
programmed  force  structure  levels,  then  identification 
of  force  structure  tradeoffs  within  mission  area  or 
mission  elements  is  required.  Tradeoffs  analysis  are 
addressed  to  the  degree  necessary  to  bring  the  force 
structure  assessment  within  current  programming  levels, 
if  possible.  The  personnel  support  package  will  be 
tested  during  OT  II." 
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Manpower  Requirements  Determination  in  MANPRINT 

Currently,  there  are  two  major  sources  of  MANPRINT 
regulatory  information.  The  first  is  AR-602-2,  MANPRINT.  The 
second  is  the  Draft  chapter  on  MANPRINT  that  will  be  included  in 
the  revised  TRADOC/AMC  PAM  70-2,  Materiel  Acquisition  Handbook 
(hereafter  referred  to  as  the  revised  TRADOC/AMC  PAM  70-2) . 

According  to  AR  602-2  (p.  27) ,  "MANPRINT  data  to  support  the 
BOIP  and  QQPRI  shall  be  developed  during  the  Proof-of-Principle 
Phase  of  the  MAP.  This  regulation  also  cites  HARDMAN  and  (ECA) 
as  two  techniques  that  can  be  used  "as  inputs  to  the  BOIP 
process"  (p.  27) . 

The  revised  AR  70-2  identifies  the  following  activities 
related  to  Manpower  Requirements  Determination  Aid  (p.  11.44  to 
11.76) : 

Requirements  and  Technology  Base  Activities  Phase 

•  Initiate  HARDMAN  and  ECA  early  in  this  phase 

Proof-of-Principle  Phase 

•  Conduct  HARDMAN 

•  Develop  input  to  BOIP  and  QQPRI 

•  Provide  input  to  ROC  on  the  "number  of  operators, 

maintainers,  and  repairers  the  new  equipment 
requires  in  each  unit."  AR  70-2  describes  the 
manpower  requirements  information  to  be  included 
in  the  ROC. 

The  revised  version  of  TRADOC/AMC  PAM  70-2  provides 
additional  information  in  manpower  determination  related  to 
MANPRINT.  According  to  this  regulation,  the  DCD  -  Materiel  and 
Logistics  System  Division,  with  input  from  DOTD,  ARI,  and  AMC 
should  provide  input  to  Required  Operational  Capability  (ROC) . 

To  provide  this  input  this  organization  should  conduct  a  force 
structure  analysis  using  information  developed  in  the  organiza¬ 
tional  plan.  The  analysis  would  determine  the  number  of  pieces 
of  new  equipment  going  into  each  type  unit  and  the  number  of 
operators,  maintainers  and  repairers  the  new  equipment  requires 
in  each  unit.  They  should  also  identify  proposed  bill-payers  to 
ensure  a  zero  growth  in  the  force  structure,  if  the  number 
required  for  the  new  system  exceeds  the  number  available  from  the 
displaced  system. 

Table  1  provides  examples  of  the  manpower  and  personnel 
information  to  be  included  in  the  ROC. 
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Table  1 

Example  of  Manpower  and  Personnel  Information  to  be  Included  in 
ROC. 


This  is  an  example  of  Manpower/Force  Structure  Assessment  to  be 
included  in  the  ROC,  para  5a: 


"a. 


OFF 

WO 

ENL 


Manpower/Force  Structure  assessment.  The  manpower  force 
structure  indicates  that  when  the  system  is  fully  fielded 
in  accordance  with  current  plans,  it  will  generate  the 
following  requirements: 


Crew 

Crew  System  & 

Per  Support 

System  Per  Unit 


Total  Army 
Aggregate 

System  Support  Total 

(Other  Units)  Army 


Total  Army  personnel  resource  requirements  are: 

Active  _ ;  savings/ increase  of  _ . 

USAR  _ ;  savings/ increase  of  _ . 

NG  _ ;  savings/ increase  of  _ .  " 


Example  of  MANPRINT  manpower  and  personnel  assessments  to  be 
included  in  the  ROC,  para  8b: 

"b.  Personnel  Assessment. 

(1)  Crew  level  cannot  exceed  three  soldiers.  No 
maintenance  task  will  require  the  use  of  more  than  one 
soldier.  Maintenance  tasks,  when  compared  to  the 
predecessor  system,  will  be  decreased  by  20%  at  the 
unit  level. 

(2)  The  target  audience  description  lists  the  expected 
aptitude  levels  (ASVAB  scores)  of  the  soldiers  who  have 
tentatively  been  identified  as  the  operators  and 
maintainers  of  the  XM99. 
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2 . 4  Users 


2.4.1  Overview  of  Users  and  Their  Functions 

Primary  Users.  Primary  MDA  users  will  be  the  Directorate  of 
Combat  Development  (DCD)  organization  within  the  TRADOC  proponent 
schools  responsible  for  developing  the  BOIP  and  QQPRI .  Usually, 
this  organization  will  be  the  Materiel  and  Logistic  System 
Division.  But  since  each  DCD  is  structured  somewhat  differently, 
the  responsible  organization  may  vary. 

As  we  develop  detailed  MDA  specifications,  we  will  identify 
the  DCD  organizations  within  each  major  TRADOC  proponent  by 
examining  the  AR  10  Series  for  each  school.  This  series  lists 
the  organization  responsible  for  producing  requirements  documents 
such  as  the  SSS  (System/Segment  Specification) . 

Secondary  Users.  Another  major  MDA  user  will  be  the  program 
manager's  staff  within  the  AMC  subordinate  command  that  provides 
input  to  the  BOIP  and  QQPRI  development  process.  Usually  this 
staff  is  the  Logistics  Division  or  Group. 

As  we  did  for  primary  users  we  will  use  the  AR  10-series  to 
develop  a  list  of  the  secondary  user  organizations.  We  will 
incorporate  this  list  into  the  detailed  design  specifications. 

Other  Users,  other  potential  users  are  the  BOIP  and  QQPRI 
reviewers  such  as  HQ  TRADOC  (DCSOPS) ;  the  Organizational 
Integrator,  or  Force  Integration  Staff  Officer  (FISO) ;  and  the 
Soldier  Support  Center-National  Capitol  Region  (SSC-NCR) .  Other 
reviewers  include  HQ  AMC  (AMCDRE) ,  the  MANPRINT  Policy  Office 
within  O DCS PER  (DAPE-ZAM) ,  and  the  MANPRINT  points-of-contact 
within  the  TRADOC  proponent  schools  and  AMC  subordinate  command. 
The  ARI  field  office  representatives  who  may  provide  MANPRINT 
support  to  TRADOC  schools  or  AMC  subordinate  commands  are  also 
potential  users. 


2.4.2  Job  Type 

The  MDA  will  be  developed  specifically  for  the  primary  users 
listed  in  the  section  above.  These  primary  users  are  the  combat 
developers  within  the  TRADOC  proponent  school  who  produce  the 
BOIP  and  QQPRI.  The  individuals  who  actually  perform  these 
functions  within  the  assigned  DCD  division  are  typically  Army 
majors  or  captains.  We  will  develop  a  more  definitive  list  of 
the  job  types  during  the  development  of  detailed  design 
specifications  for  the  MDA.  In  order  to  do  this,  we  will  contact 
the  appropriate  division  for  DCDs  for  the  major  TRADOC  proponent 
schools.  A  sample  of  these  organizations  will  be  contacted  in 
the  next  three  months  so  that  we  can  present  preliminary  results 
in  our  final  concept  paper. 
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.4.3  Additional  Information  on  Users 

During  the  development  of  the  detailed  design 
specifications,  we  will  gather  additional  information  on  1)  user 
training  background  and  2)  current  and  projected  hardware  and 
software  available  to  users.  We  will  develop  this  information  by 
contacting  the  appropriate  division  for  DCDs  for  the  major  TRADOC 
proponent  schools. 


2 . 5  Assumptions 

The  following  assumptions  underly  development  of  the  MDA: 

Manor  System  Focus.  The  MDA  will  describe  manpower 
requirements  for  major  weapon  systems.  Although  the  general 
logic  of  the  MDA  applies  to  other  types  of  systems,  we  will 
develop  the  MDA's  automated  tools  only  for  major  systems. 

Availability  of  HOS  Subroutines.  The  approach  we  are 
proposing  for  the  MDA  includes  embedded  access  to  Human  Operator 
Simulation  (HOS)  modeling.  The  current  ARI  supported  effort 
towards  the  modification  of  HOS  will  result  in  subroutines  that 
are  coded  in  the  C  programming  language. 

Difference  Between  Force  Structure  Analysis  and  Manpower 
Determination .  The  MDA  is  an  aid  for  determining  manpower.  It 
is  not  a  force  structure  analysis  tool.  A  manpower  determination 
analysis  determines  the  number  of  operators  and  maintainers 
needed  to  support  a  particular  weapon  system.  A  force  structure 
analysis  determines  the  size  and  composition  of  Army  units. 

Force  structure  analysis  considers  tasks  beyond  those  associated 
with  individual  weapon  systems.  It  also  assesses  the  impact  of 
personnel  and  equipment  attrition  during  wartime. 

Attrition  is  beyond  the  scope  of  manpower  determination  as 
described  in  Army  acquisition  documents.  As  a  result,  tools  such 
as  AMORE  that  deal  with  attrition  cannot  provide  a  basis  for 
manpower  determination. 

Operator  and  Maintainer  Differences  in  Manpower 
Determination .  The  basic  logic  underlying  determination  of 
maintenance  and  operator  manpower  requirements  is  the  same.  It 
involves  dividing  workload  demand  by  capacity.  However,  the 
specific  elements  used  to  calculate  them  in  our  concept  are  quite 
different.  Maintenance  workload  is  determined  by  computing  total 
maintenance  manhours  for  a  given  period  (usually  a  fairly  long 
period  such  as  a  year)  and  then  dividing  the  results  by  a  measure 
of  capacity  such  as  annual  available  maintenance  manhours. 
Operator  workload  is  determined  by  examining  cognitive  and 
perceptual  and  physical  workload  at  particular  points  in  time  and 
then  comparing  this  workload  with  the  human  capabilities  for 
dealing  with  it.  Our  approach  for  determining  manpower 
requirements  reflects  these  differences.  We  will  develop  network 
models  to  represent  both  operator  and  maintainer  tasks. 
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We  will  evaluate  operator  manning  based  on  an  operator 
workload  model  that  McCracken  and  Aldrich  developed  (1984) . 
Although  we  could  use  the  same  approach  for  maintainers,  we  have 
chosen  to  represent  maintainer  tasks  use  Micro  SAINT  networks. 

The  networks  resemble  the  ones  that  have  been  used  to  describe 
maintenance  performance  in  a  wide  range  of  studies.  Such  studies 
include  the  Coordinated  Human  Resource  Technology  (Askren  and 
Goclowski,  1978)  and  the  Air  Force  Logistic  Composite  Model  that 
the  Air  Force  used  to  determine  maintenance  manpower 
requirements. 

Contractor  Inputs  to  MPA.  We  assume  that  the  prime 
contractor  will  provide  information  on  the  human  interface 
design.  This  information  includes  a  description  of  the  operation 
and  maintenance  of  all  major  system  components,  including  support 
equipment  (with  particular  emphasis  on  controls  and  displays) . 
Basically,  the  contractor  will  provide  the  level  of  information 
required  by  the  Type  B1  specification  of  Prime  Item  Development 
Specification  (see  MIL-STD-490) . 

The  MDA  will  not  require  information  on  system  tasks,  task 
performance  times,  or  accuracies  from  the  contractor.  The  MDA 
itself  will  provide  procedures  for  generating  these  information 
elements. 

Use  of  Army  Manpower  Algorithms  and  Allowances .  The  MDA 
will  use,  without  modification,  the  basic  manpower  determination 
algorithm  for  variable  positions  in  AR  570-2.  It  will  also 
incorporate  the  work  capacity  factors  listed  in  AR  570-2  and  the 
Standards  of  Grade  Authorization  found  in  AR  611-201. 

Personnel  and  Training  Assumptions.  This  concept  paper 
focuses  on  the  MDA 1 s  initial  application.  In  this  first  applica¬ 
tion,  workload  estimates  are  based  on  an  assumption  that  (1) 
personnel  with  the  median  level  of  personnel  characteristics  (as 
determined  by  the  Personnel  Requirements  Estimation  Aid)  are 
performing  the  tasks,  and  (2)  the  type  and  amount  of  training 
these  personnel  have  received  is  that  which  is  most  likely  to  be 
assigned  (as  determined  by  the  Training  Constraints  Estimation 
Aid)  . 


The  MDA  will  be  iterated  in  subsequent  tradeoff  analyses  as 
part  of  the  application  of  the  MPT  Tradeoff  Analysis  Aid.  These 
tradeoffs  will  explore  different  assumptions  about  personnel  and 
training. 

Job  Determination.  The  MDA  will  help  identify  jobs.  The 
analysis  will  define  operator  jobs  by  assigning  specific  tasks  to 
duty  positions.  This  concept  is  congruent  with  the  Army's  Job 
Books  which  break  out  operator  tasks  by  duty  position.  After  the 
assignments  have  been  made,  the  MDA 1 s  automated  steps  will  assess 
how  these  assignments  affect  workload  and  system  capability. 
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Maintenance  jobs  are  defined  by  assigning  specific  tasks  to 
MOS  and  skill  level  combinations  at  particular  maintenance 
levels.  The  Army  does  not  have  duty  positions  for  maintainers. 
The  MDA  will  include  procedures  for  assigning  maintenance  tasks 
to  MOS  and  skill  level  combinations. 

2.6  High  Level  Functional  Requirements 
2.6.1  Technical  Requirements 

Outputs.  The  MDA  must  output  quantitative  manpower 
requirements,  by  job,  for  a  specific  contractor  design.  These 
manpower  requirements  will  include:  (1)  operator  manpower 
requirements,  (2)  maintenance  manpower  requirements,  and  (3) 
Direct  Productive  Annual  Maintenance  Manhours  (DPAMMH) . 


For  maintenance  the  MDA  will  also  be  capable  of  breaking  out 
manpower  requirements  by  MOS,  skill  level,  major  component  item 
(maintainers  only) ,  and  maintenance  level  (maintainers  only)  and 
will  be  capable  of  breaking  out  all  estimates  at  both  the  single 
system  and  aggregate  level. 

In  addition  to  producing  estimates  of  manpower  requirements, 
the  MDA  will  produce  estimates  of  system  availability, 
reliability,  and  operational  effectiveness.  These  estimates  will 
be  compared  with  the  requirements  for  these  criteria  identified 
by  the  System  Performance  Requirements  Estimation  Aid  (SPREA) 
identified  during  the  Requirements  Technology  and  Base  Activities 
phase  of  the  MAP.  Based  on  this  comparison,  shortfalls 
(discrepancies  between  requirements  and  estimates  based  on 
contractor  designs)  will  be  identified. 

Role  in  Acquisition  Process.  The  MDA  information  on 
manpower  requirements  must  be  designed  to  feed  directly  into  the 
BOIP  and  QQPRI . 

Users.  The  MDA  must  be  specifically  designed  for  use  by  the 
combat  developers  within  the  TRADOC  proponent  school  who  produce 
the  BOIP  and  QQPRI. 

2.6.2  Acceptability  and  Usability  Requirements 

The  previous  sub-section  presented  an  overview  of  the 
technical  requirements  that  must  be  met  by  the  MDA.  This  section 
describes  some  of  the  acceptability  and  usability  requirements 
which  also  must  be  met  by  these  tools. 

Produce  Tailored  User  Outputs  and  Processes.  Previous  &&D 
products  have  not  been  implemented  because  they  failed  to  meet 
the  needs  of  individual  Army  decision  makers.  They  were  R&D 
products  ”in  search  of  users”.  To  avoid  this  problem  in  the 
current  effort,  it  is  critical  that  specific  users  be  identified 
for  the  MDA.  Furthermore,  the  outputs  of  the  MDA  should  be 


formatted  so  that  Army  users  can  insert  them  directly  in  MAP 
documents.  Additionally  the  aids  must  be  capable  of  producing 
results  in  a  timely  fashion  and  be  capable  of  meeting  the 
requirements  of  the  new  streamlined  acquisition  process.  The 
latter  requirements  indicate  a  need  for  using  some  form  of 
automation  tc  support  each  product  whenever  it  is  cost  effective 
to  do  so.  Finally,  to  develop  products  that  meet  users  needs, 
users  must  be  involved  in  all  phases  of  product  development. 

Describe  "How  To”  Procedures.  Sufficient  ”how  to” 
procedures  must  be  included  in  the  MDA  to  allow  Army  users  with 
minimal  training  to  apply  each  product.  Whenever  possible, 
procedures  should  be  automated  to  reduce  user  analysis 
requirements.  However,  for  all  automated  tools,  detailed 
procedures  for  obtaining  input  data  and  interpreting  results 
should  be  presented.  For  all  manual  tools,  detailed  instructions 
for  conducting  each  analytical  step  should  be  provided. 

Minimize  Organizational  Impacts.  The  MDA  must  be  designed 
to  fit  the  user  and  not  vice  versa.  Consequently,  they  must  not 
require  additional  personnel  to  apply  or  cause  restructuring  of 
existing  Army  organizations;  they  must  utilize  computer  hardware 
available  at  user  locations  or  accessible  via  secure  lines. 
Furthermore,  they  should  use  existing  software  whenever  possible 
and  if  they  require  new  software  packages,  the  cost  of  these 
packages  must  not  exceed  the  typical  software  acquisition  budget 
for  these  users. 

Minimize  User  Training.  The  members  of  the  MAP  community 
who  are  expected  to  be  users  of  the  MDA  are  already  overburdened 
and  understaffed.  In  addition,  they  are  trying  to  meet 
increasing  acquisition  requirements  such  as  MANPRINT  within  the 
context  of  the  streamlined  acquisition  process.  Consequently, 
training  time  for  the  (MPT)2  products  must  be  minimized.  This 
requires  development  of  user  interfaces  that  require  no  prior 
computer  experience.  For  example,  the  interface  should  contain 
built-in  job  aids  (e.g.,  help  commands).  Finally,  when  formal 
training  is  required,  it  must  be  developed  in  accordance  with 
Army  instructional  system  design  principles  and  utilize  only 
media  that  are  readily  available  or  accessible  to  users. 

Security.  The  MDA  may  be  required  to  accept  classified  data 
and  must  be  designed  to  provide  acceptable  levels  of  security. 
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SECTION  3  -  WORKLOAD  ANALYSIS  AID 
3 . 1  Overview 

The  purpose  of  this  module  of  the  MDA  is  to  provide  Army 
analysts  with  an  aid  for  determining  the  manpower  required  to 
successfully  perform  required  mission  functions  for  a  proposed 
system  design. 

The  Workload  Assessment  Aid  (WAA)  will  assist  the  analyst 
in  determining  a  probable  staffing  plan  and  the  feasibility  of 
successfully  performing  the  mission  functions,  given  that  plan, 
within  the  manpower  constraints  that  were  established  as  an 
output  of  Product  2.  The  staffing  plan  will  be  defined  by  the 
following: 


•  The  different  jobs  or  crew  positions  required. 

•  The  tasks  assigned  to  each  job. 

•  The  number  of  crew  members  required  for  each  job. 

The  initial  application  of  the  WAA  will  be  based  on  the  following 
assumptions: 

1.  The  operators  are  given  an  average  or  expected  amount 
of  training  (as  determined  by  Product  4) . 

2 .  The  operators  have  personnel  characteristic  values 
equal  to  the  values  set  by  product  3,  the  PCEA. 

The  WAA  will  use  the  basic  approach  of  hypothesis  testing 
and  operator  workload  analysis  to  identify  the  manpower  required 
to  successfully  operate  a  proposed  system  design.  In  other 
words,  with  the  help  of  the  WAA,  the  analyst  will  develop  a 
hypothetical  list  of  jobs,  tasks  per  job,  and  numbers  of  people 
per  job  and  then  test  the  feasibility  of  this  configuration  with 
respect  to  operator  workload.  By  this  we  mean  that  the  analyst 
will  use  the  WAA  to  define  a  staffing  plan  and  a  mission 
scenario.  The  WAA  will  use  this  (and  other)  information  to 
create  and  execute  a  network  simulation  that  will  determine  the 
workload  requirements  of  each  crew  member.  When  the  simulation 
indicates  that  the  proposed  allocation  of  tasks  to  jobs  results 
in  excessively  high  workload  for  one  or  more  of  the  operators,  it 
means  that  the  average  operator  probably  can't  do  the  job. 
Therefore,  job  and  task  reallocation,  more  operators,  or  a  change 
in  the  system  design  are  necessary  to  reduce  the  workload  to 
acceptable  levels. 
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The  analyst  will  continue  to  manipulate  the  configuration 
of  jobs  and  tasks  per  job  until  he  or  she  finds  a  configuration 
that: 

•  does  not  produce  excessively  high  workload  for  any  of 
the  crew  members. 

•  meets  the  system  performance  requirements. 

•  falls  within  system  design  and  manpower  constraints. 

When  all  of  the  above  criteria  have  been  met  by  a  staffing 
plan  for  a  given  system  design,  the  WAA  will  produce  a  set  of 
manpower  requirements  reports  that  indicate: 

•  the  different  operations  or  crew  jobs  that  were 
required. 

•  the  tasks  that  were  ultimately  assigned  to  each  job. 

•  the  number  of  people  required  for  each  job. 

•  a  summary  of  the  workload  requirements  for  each  of  the 
operators . 

•  the  mission  scenario  parameters  for  which  the  analysis 
was  conducted . 

•  a  time  line  analysis  of  task  performance  times  and 
accuracies. 

During  the  tradeoff  analyses  conducted  with  Product  6,  the 
WAA  can  be  iterated  with  alternative  assumptions  about  the 
personnel  characteristics  and  amount  of  training  received. 

We  should  note  that  the  purpose  of  this  aid  is  not  to 
predict  crew  performance  under  conditions  of  operator  overload. 

To  do  this  would  add  greatly  to  the  complexity  of  this  tool  as 
well  as  to  create  a  need  for  empirical  research  to  benchmark  the 
tool.  Rather,  the  purpose  of  the  WAA  is  to  verify  that  a  given 
system  design  with  a  given  staffing  plan  will  not  result  in 
levels  of  required  workload  which  will  exceed  the  capacity  of  the 
individuals  and  the  crew.  With  this  tool,  the  analyst  will  be 
able  to  determine  points  of  operator  overload  which  can  lead  to 
recommendations  for  system  design  changes  and  staffing  changes. 

By  avoiding  the  need  for  quantitative  estimates  of  levels  of 
performance  degradation  under  overload,  we  have  reduced  the 
complexity  of  the  aid  and  maintained  the  proper  focus  of  the  aid 
—  for  the  determination  of  manpower  requirements. 
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The  WAA  will  take  as  input  the  system  design,  a  task 
analysis,  and  the  operator  staffing  plan.  The  WAA  will  also 
assist  the  analyst  in  adding  information  to  this  including  1) 
task  performance  times,  2)  task  workload  values,  and  3) 
information  about  specific  mission  scenarios.  Then,  using 
operator  workload  assessment  techniques  which  were  developed  and 
tested  in  other  applications  (e.g.,  Laughery,  Drews,  Archer,  and 
Kramme,  1986) ,  the  WAA  will  compute  points  at  which  operator 
workload  requirements  exceed  operator  workload  capacity  (as 
defined  by  the  analyst) . 

These  points  of  excessive  workload  indicate  deficiencies  in 
the  staffing  plan  and  the  system  design.  The  analyst  will  use 
the  WAA  to  address  these  deficiencies  through  a  new  definition  of 
jobs,  a  re-allocation  of  tasks  for  each  of  the  defined  jobs,  or 
increasing  the  number  of  operators  that  are  used  to  perform  each 
job. 

•i 

Let  us  explain  the  theory  and  application  of  this  workload 
analysis  methodology  to  provide  a  clearer  context  for  the 
approach . 

3.1.1  The  Theory  Behind  the  WAA 

Most  conventional  techniques  (e.g.,  SWAT)  for  assessing 
operator  workload  focus  on  subjective  examinations  of  workload  by 
experts.  Additionally,  they  tend  not  to  define  specific  segments 
of  the  mission  where  workload  is  excessive. 

Micro  Analysis  and  Design  has  used  computer  modeling  and 
simulation  of  the  operators  activities  for  the  purpose  of 
evaluating  points  of  high  operator  workload  in  Army  helicopters. 
The  approach  is  applicable  for  quantitatively  predicting  operator 
workload  in  the  earliest  stages  of  design.  The  technology  behind 
the  technique,  task  network  modeling,  involves  a  computer 
simulation  of  human  operator  performance  within  the  context  of 
the  system  (hardware  and  software)  and  environment. 

The  fundamental  approach  to  evaluating  operator  workload  is 
to  develop  a  computer  simulation  of  the  operator  performing  his 
activities  within  the  context  of  the  system  he  is  operating  and 
the  mission  he  is  performing.  We  will  discuss  the  approach  for 
developing  operator  computer  models  in  some  detail.  However,  to 
set  the  stage,  first  let  us  discuss  the  general  modeling  approach 
used,  task  network  modeling,  and  the  specific  modeling  system, 
Micro  SAINT. 
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The  Tools:  Task  Network  Modeling  and  Micro  SAINT 

In  previous  workload  analyses  in  which  Micro  Analysis  and 
Design  has  been  involved,  models  were  developed  by  creating  task 
networks.  Task  network  modeling  involves  the  decomposition  of 
system  performance  into  a  series  of  subactivities  or  tasks  (e.g., 
a  task  analysis  for  a  human  operator,  a  functional  analysis  for  a 
helicopter) .  Then,  the  sequencing  of  tasks  is  defined  by 
constructing  a  task  network.  A  task  network  may  also  include 
several  relatively  autonomous  subnetworks  which,  while 
interrelated,  are  also  very  distinctly  separate  such  as 
relatively  autonomous  networks  for  the  operator,  hardware  and 
software,  and  threats. 

Additional  information  which  is  required  to  make  a  model 
"run"  include  the  following  for  each  task: 

1.  The  mean  time  required  to  perform  a  task  and 
associated  distribution  parameters 

2 .  The  state  of  the  system  before  a  task  could  commence 
(e.g.,  equipment  availability,  the  aircraft  being  at  a 
specific  location) 

3.  The  task  or  tasks  which  will  follow  when  the  current 
task  is  completed 

4.  For  tasks  which  may  be  followed  by  several  tasks,  the 
logic  associated  with  selection  of  the  task  or  tasks 
which  will  commence  after  this  one  is  completed 

Micro  SAINT  is  a  product  that  was  developed  for  the  Army 
specifically  to  simplify  and  accelerate  the  development  and  use 
of  task  network  models.  Micro  SAINT  permits  the  modeler  to 
construct  and  run  all  segments  of  a  task  network  model  by  using 
menus  rather  than  writing  computer  code.  Micro  SAINT  will  not  be 
the  only  tool  for  the  WAA,  but  it  will  serve  as  the  building 
block  from  which  our  software  will  be  constructed  for  the 
simulation  portion  of  the  WAA. 

Let  us  now  discuss  task  network  modeling  as  applied  to 
workload  assessment.  A  sample  task  network  model  for  an  operator 
of  an  attack  helicopter  is  presented  in  Figure  2.  Note  that  this 
is  a  high  level  diagram  and  that  each  node  in  this  network 
can  be  represented  by  one  or  more  detailed  sub-networks  such  as 
the  one  presented  in  Figure  3  for  communications.  It  is 
conceivable  that  workload  analysis  could  be  conducted  at  either 
level,  depending  upon  the  availability  of  data. 
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Figure  2.  Sample  Operator  Task 
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Figure  3.  Sample  of  a  Detailed  Operator  Task  Network. 
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To  evaluate  points  of  excessive  operator  workload,  we 
propose  a  variation  on  a  technique  which  has  been  used  by 
McCracken  and  Aldrich  (1984) .  Using  this  technique,  each 
operator  activity  is  characterized  by  the  workload  demand 
required  in  each  of  four  channels,  the  auditory  channel,  the 
visual  channel,  the  cognitive  processing  channel,  and  the 
psychomotor  output  channel.  McCracken  and  Aldrich  present 
benchmark  scales  for  determining  demand  for  each  channel.  As  an 
example,  the  scale  for  visual  attentional  demands  is  presented 
below: 


Value: 


Activity, 


1  Monitor,  scan,  survey 

2  Detect  movement,  change  in  size,  brightness 

3  Trace,  follow,  track 

4  Align,  aim,  orient 

5  Discriminate  symbols,  numbers,  words 

6  Discriminate  based  on  multiple  aspects 

7  Read,  decipher  text,  decode 


Using  this  approach,  each  operator  task  can  be 
characterized  as  requiring  some  amount  of  each  of  the  four  kinds 
of  attentional  demand.  All  tasks  in  the  operator  models  are 
analyzed  with  respect  to  these  demands  and  values  are  assigned 
accordingly. 


However,  an  operator  is  frequently  not  performing  simply 
one  task  at  a  time.  For  example,  he  may  be  required  to  monitor 
his  hover  position  while  he  receives  a  communication.  Given 
this,  the  workload  literature  indicates  that  the  operator  may 
either  accept  the  increased  workload  or  begin  dumping  tasks  he 
perceives  as  less  important1. 


*We  are  fully  cognizant  of  the  "serial"  vs.  "parallel" 
processing  theories  as  well  as  other  multitask  human  information 
processing  theories  that  are  currently  being  debated.  We  do  not 
wish  to  minimize  the  impact  of  these  theories  on  our  approach. 

We  recognize  that  they  are  substantial.  However,  if  we  maintain 
the  focus  that  the  WAA  is  to  identify  points  of  high  workload, 
not  hypothesizing  how  humans  will  process  information  during 
these  periods,  then  we  believe  that  it  is  reasonable  to  treat 
these  tasks  which  the  human  must  perform  within  the  same  time 
frame  as  being  performed,  essentially,  simultaneously. 
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To  factor  these  two  issues  into  the  computer  simulations, 
two  approaches  can  be  incorporated:  1)  evaluate  combined  operator 
workload  demands  for  tasks  which  are  being  performed  concurrently 
or  2)  determine  when  the  operator  would  begin  dumping  tasks  due 
to  overload.  Our  method  focuses  on  the  first  approach. 

Since  the  operator  would  frequently  need  to  perform  several 
tasks  simultaneously  and  each  task  would  have  attentional  demands 
according  to  the  McCracken  and  Aldrich  scale,  we  are  able  to 
evaluate  total  attentional  demands  for  each  of  the  four  channels 
(visual,  auditory,  psychomotor,  and  cognitive)  during  a 
simulation  by  simply  summing  the  attentional  demands  across  all 
tasks  which  are  being  performed  simultaneously.  For  example,  let 
us  assume  that  at  some  point  in  the  mission,  the  operator  is 
simultaneously  reading  the  altimeter  to  compare  his  current 
altitude  while  he  is  looking  at  the  multifunction  display  to 
evaluate  his  weapons  status.  Let  us  assume  that  the  attentional 
demands  of  these  tasks  are  as  follows: 


Check  Evaluate  Combined 
Channel  Altitude  Weapons  Tasks 

Visual  32  5 
Auditory  10  1 
Cognitive  25  7 
Psychomotor  00  0 


The  last  column  above  indicates  what  his  combined 
attentional  demands  for  each  of  the  four  channels  are.  We  are 
aware  that  simple  summation  of  attentional  demands  into  a 
combined  score  may  not  be  fully  indicative  of  combined 
attentional  demands.  However,  there  are  some  levels  of 
attentional  demands  across  tasks  for  which  we  can  reasonably 
expect  operator  difficulties.  In  the  WAA,  we  will  provide  the 
analyst  with  the  opportunity  to  define  operator  "overload”  at 
whatever  magnitude  he  chooses  with  some  guidance  provided  as  to 
appropriate  values. 

In  the  computer  simulations,  we  are  able  to  assign  values 
for  the  attention  required  in  each  of  the  four  channels  for  each 
task.  Then  using  Micro  SAINT,  we  can  obtain  an  estimate  at  any 
point  in  the  simulation  of  the  total  attentional  demands  across 
all  tasks.  By  collecting  data  during  a  simulation  run,  we  are 
able  to  characterize  the  operator's  attentional  requirements 
graphically.  Figure  4  shows  an  example  of  a  graph  for  visual 
attention  in  an  experiment  conducted  by  Micro  Analysis  and  Design 
for  a  helicopter  operator  workload  analysis.  By  examining  the 
points  in  the  mission  at  which  these  attentional  demands  are 
high,  we  can  assess  mission  segments  for  which  operator  workload 
will  be  excessive  and,  therefore,  we  can  either  expect  degraded 
performance,  change  task  allocation  across  operators,  or  define  a 
need  for  more  operators. 


cumulative  attention 


ATTENTION  THROUGHOUT  A  RUN 


Figure  4.  Sample  of  Visual  Attentional  Demands  Throughout  a 
Helicopter  Mission 
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Additionally,  we  can  look  at  aggregate  attention  demands  by 
examining  histograms  such  as  the  one  presented  in  Figure  5 . 


ATTENTION 


Figure  5.  Sample  of  Histogram  Presenting  Visual  Attentional 
Demands  Throughout  a  Helicopter  Mission. 


While  the  above  analysis  may  seem  unwieldy  to  someone  with 
simulation  experience,  modern  software  tools  make  this  analysis 
very  straightforward.  As  an  example,  Table  2  presents  some  labor 
statistics  for  an  analysis  of  helicopter  crew  performance. 
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Table  2 


LABOR  STATISTICS  ASSOCIATED  WITH  THE 
HELICOPTER  WORKLOAD  MODELING  EFFORT 

1.  Professional  effort 
required  to  develop  Crew  Task 
analysis  of  four  cockpits 

2.  Professional  effort 
required  to  develop  paper 
model  of  the  helicopter 

3.  Professional  effort 
required  to  develop  paper 
model  of  threats 

4.  Time  to  develop  computer 
simulation  from  paper 
models  and  task  analysis 

5.  Time  to  execute  one  run 

6.  Time  to  conduct  data  analyses 

(including  generation  of 
graphics)  4  man-days 


Total  elapsed  time  from 
beginning  of  effort  to 

submission  of  draft  report  10  weeks 


In  constructing  the  WAA,  we  will  develop  a  set  of  user 
interface  templates  and  custom  software  to  create  Micro  SAINT 
simulation  models  as  described  above.  Because  these  portions  of 
the  WAA  will  be  aimed  directly  at  operator  workload  analysis,  the 
user  of  these  tools  will  be  able  to  conduct  the  above  type  of 
analysis  without  having  any  knowledge  of  computer  simulation, 
only  of  the  operator  tasks  and  missions. 

3.1.2  Overview  of  the  WAA  Approach 

The  basic  approach  that  the  analyst  will  use  to  determine 
the  manpower  requirements  for  operators  of  a  new  or  modified 
system  design,  will  be  hypothesis  testing.  The  analyst  will 
develop  a  hypothesis  that  consists  of  a  description  of  the  jobs 
or  crew  positions  that  will  be  required  by  the  system  design,  the 
tasks  that  will  be  assigned  to  each  of  the  jobs,  and  the  number 
of  crew  members  that  will  be  needed  to  fill  each  job.  This  set 
of  jobs,  tasks  per  job,  and  number  of  operators  per  job  is 
defined  as  the  staffing  plan. 


30  man-days 

3  man-days 

2  man-days 

40  man-days 
45  minutes 


The  WAA  will  assist  the  analyst  in  developing  a  staffing 
plan  by  providing  access  to  operator  staffing  information  for 
comparable  fielded  systems. 

The  analyst  will  test  the  initial  staffing  plan  by 
simulating  the  activities  of  the  crew  members  as  they  perform 
mission  functions  for  which  the  system  was  designed.  The  purpose 
of  the  simulation  is  to  measure  the  visual,  auditory,  cognitive 
processing,  and  psychomotor  workload  of  each  operator. 

If  the  results  of  the  simulation  indicate  that  the  workload 
of  one  or  more  of  the  crew  members  is  excessive,  it  means  that 
the  average  operator  probably  won't  be  able  to  do  the  job  witnout 
dumping  some  tasks  to  perform  others  or  decreasing  the 
proficiency  of  performing  all  tasks.  When  this  is  the  case,  the 
analyst  will  need  to  modify  the  staffing  plan  to  re-allocate 
tasks  to  different  jobs  or  consider  adding  more  operators. 
However,  the  analyst  must  keep  in  mind  that  the  number  of 
operators  and  the  tasks  that  can  be  assigned  to  a  particular 
operator  may  be  constrained  by  the  system  design.  For  example, 
if  the  design  is  a  cockpit  that  has  only  two  seats,  the  design 
itself  has  constrained  the  number  of  operators.  The  system 
design  can  also  constrain  the  allocation  of  tasks  due  to  an 
operator's  access  to  the  task  that  needs  to  be  performed.  For 
example,  if  a  proposed  helicopter  design  has  a  seat  for  the 
gunner,  and  a  seat  for  the  pilot,  and  the  simulation  indicates 
that  the  gunner  is  experiencing  excessive  overload  in  a  number  of 
mission  segments,  it  may  not  be  possible  to  re-allocate  some  of 
the  gunner's  tasks  to  the  pilot  due  to  the  fact  that  the  pilot 
may  not  have  access  (given  the  design)  to  the  gunnery  controls. 

After  modifying  the  staffing  plan,  the  analyst  will  re-run 
the  simulation  to  test  the  new  hypothesis.  When  the  results  of 
the  simulation  model  indicate  that  the  workload  of  all  of  the 
system  operators  is  within  the  capacities  of  average  operators, 
the  analyst  will  compare  the  simulated  system  performance  with 
the  output  of  the  System  Performance  Requirements  Estimation  Aid 
(Product  1) .  If  the  system  performance  is  within  what  is 
required,  the  analyst  will  compare  the  staffing  plan  with  the 
manpower  constraints  that  were  derived  as  an  output  of  Product  2 . 

In  other  words,  the  analyst  will  continue  to  test 
hypothetical  staffing  plans  in  an  attempt  to  find  a  configuration 
of  jobs,  tasks  per  job,  and  number  of  operators  per  job  that: 

•  does  not  produce  excessively  high  workload  for  any  of 
the  operators. 

•  meets  the  system  performance  requirements. 

•  falls  within  the  system  design  and  manpower 
constraints . 
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When  a  staffing  plan  for  a  system  design  cannot  meet  all  of 
the  above  requirements,  then  the  manpower  requirements  for  that 
design  are  unclear.  The  reason  for  this  is  that  the  manpower 
requirements  depend  on  which  of  the  above  constraints  are 
violated.  If  the  performance  requirements  are  violated,  the 
number  of  operators  may  be  able  to  stay  within  the  manpower  and 
workload  constraints.  If  the  manpower  constraints  are  violated, 
the  crew  may  be  able  to  operate  the  system  within  the  performance 
requirements,  etc. 

To  further  complicate  this  issue,  as  we  stated  at  the 
outset,  the  WAA  analysis  assumes  an  average  operator  with  an 
average  amount  of  training.  The  manpower  requirements 
deficiencies  discussed  above  could  possibly  be  resolved  by 
considering  operators  with  other  personnel  characteristics  or 
amounts  of  training.  However,  these  kinds  of  trade-offs  are  not 
within  the  scope  of  the  WAA  or  the  MDA.  Therefore,  when  a 
staffing  plan  for  a  system  design  cannot  be  identified  that  will 
fall  within  the  workload,  performance,  and  manpower  constraints, 
a  product  6  Personnel  Requirements  Analysis  will  be  required. 

The  hypothesis  testing  and  workload  analysis  approach  to 
determining  manpower  requirements  for  system  operators  offers 
several  advantages.  The  first  is  the  fact  that,  in  most  cases, 
the  analyst  will  not  find  it  difficult  to  define  jobs  and  to 
identify  the  tasks  that  will  be  assigned  to  each  job.  However, 
when  it  is  not  clear  which  tasks  should  be  assigned  to  which  jobs 
or  how  many  operators  it  will  take,  the  workload  modeling  will 
tell  the  analyst  who  is  busy  and  who  isn’t.  Another  advantage  is 
that,  no  matter  how  jobs  and  tasks  per  job  are  defined,  the 
analyst  needs  to  know  whether  the  operators  can  actually  do  the 
tasks  that  have  been  assigned  to  them.  From  a  Product  5  point  of 
view,  an  operator's  ability  to  perform  the  tasks  that  constitute 
a  job  is  controlled  by: 

•  The  sequence  of  tasks  that  must  be  performed.  When  a 
number  of  tasks  need  to  be  performed  in  parallel,  it 
may  not  be  feasible  to  assign  those  tasks  to  a  single 
job,  no  matter  how  similar  they  are.  The  workload 
analysis  performed  by  the  WAA  identifies  parallel 
tasks  that  result  in  excessive  workload  for  one 
operator. 

•  The  supportabilitv  of  the  system  design.  Regardless 
of  how  jobs  are  defined,  the  system  design  must  be 
able  to  support  those  jobs.  For  example,  if  a 
workload  analysis  indicates  that  a  design  for  a  single 
seat  cockpit  results  in  excessive  workload  for  the 
operator,  it  is  useless  to  suggest  that  more  than  one 
operator  is  needed  unless  the  system  is  re-designed  to 
support  two  operators. 
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•  The  accessibility  of  the  operators  to  the  controls  and 
displays  associated  with  tasks  they  must  perform. 

Crew  members  can't  be  assigned  tasks  to  operate 
equipment  that  they  don't  have  access  to.  A  simple 
example  of  this  is  that  an  operator  who  is  assigned  to 
a  workstation  must  be  able  to  reach  equipment  he  is 
expected  to  operate.  In  other  words,  a  tank  driver 
probably  can't  be  expected  to  load  the  main  gun  if  he 
is  expected  to  stay  in  the  driver's  seat  even  if  he 
had  the  time. 

Let  us  now  go  into  some  detail  about  the  steps  the  analyst 
using  the  WAA  will  need  to  follow,  the  outputs  produced  by  the 
WAA,  the  software  elements  that  will  be  developed  in  creating  the 
WAA,  and  the  steps  involved  in  developing  these  software 
elements . 

3.1.3  Steps  the  Analyst  Will  Follow  in  Using  the  WAA 

The  steps  that  the  analyst  will  follow  in  using  the  WAA  to 
estimate  the  manpower  requirements  of  a  system  design  depend  on 
the  amount  of  information  that  is  provided  by  the  contractor.  If 
the  contractor's  design  documentation  includes  a  task  analysis  of 
the  operator  activities  and  a  staffing  plan  that  defines  jobs  and 
assigns  tasks  to  those  jobs,  the  steps  involved  in  evaluating 
that  staffing  plan  are  relatively  straightforward.  However,  it 
is  very  likely  that  the  contractor  won't  supply  all  of  this 
information.  When  this  is  the  case,  the  analyst  will  have  to 
generate  the  missing  information  from  other  sources.  In  general, 
the  less  information  supplied  by  the  contractor,  the  more  work 
the  analyst  will  have  to  do. 

In  applying  the  WAA,  the  analyst  will  perform  eleven  basic 
steps.  Section  3.2  contains  a  detailed  discussion  of  each  step 
and  the  sub-steps  that  are  included  within  each  step. 


Following  is  a  brief  description  of  the  steps  (page  number 
references  for  the  detailed  discussion  in  Section  3.2  are 
included) : 


1.  Develop  a  list  of  the  tasks  in  the  system  design  that 
will  be  assigned  to  operators.  (see  page  El-59) 

2.  Define  all  crew  positions  (jobs).  (see  page  El-63) 

3.  Initially  assign  tasks  to  jobs.  (see  page  El-68) 

For  each  mission  to  be  analyzed,  develop  sequential 
relationships  between  operator  tasks  (if  they  are  not 
included  specifically  in  the  task  analysis) .  (see 
page  El-70) 


4. 


5. 


Based  on  comparability  analysis,  motion-time 
estimation  techniques,  subject-matter  expert 
estimates,  or  HOS  modeling,  develop  performance  times 
and  accuracies  for  each  operator  task,  (see  page  El- 
82) 

6.  Assign  workload  values  to  each  operator  task  (one 
value  for  each  workload  channel  [i.e.,  visual, 
auditory,  cognitive,  and  psychomotor  workload]).  (see 
page  El-89) 

7.  For  each  scenario  to  be  studied  within  each  mission, 
develop  descriptions  of  any  additional  environmental, 
tactical,  or  other  system  conditions  which  are  to  be 
included  in  the  analysis.  (see  page  El-90) 

8.  Exercise  the  computer  simulation  (which  will  be 
created  directly  from  files  generated  during  the  above 
seven  steps) .  This  simulation  will  be  exercised  for 
each  mission  type  and  each  scenario  within  a  mission 
type.  (see  page  El-93) 

9.  Review  the  output  of  the  computer  simulation ( s) .  (see 
page  El-95) 

10.  Determine  acceptability  of  operator  staffing  plan  and, 
if  discrepancies  exist  between  required  operators  and 
available  operators,  define  the  points  at  which 
solutions  to  operator  overload  must  be  found.  (see 
page  El-111) 

11.  Reallocate  tasks  to  jobs  or  add  operators  in  a  way 
that  would  result  in  successful  system  operation  and 
acceptable  operator  workload.  (see  page  El-112) 

The  sequencing  of  these  steps  is  presented  in  Figure  6. 
3.1.4  Outputs  of  the  WAA 

All  outputs  of  the  WAA  will  be  presented  for  a  given 
mission  type  and  a  given  mission  scenario  (including 
environmental  and  tactical  conditions) .  For  each  mission 
scenario,  the  WAA  will  produce  a  variety  of  different  analyses 
for  the  analyst  to  use  in  evaluating  overall  workload  across  a 
mission.  Also,  the  WAA  will  provide  the  analyst  with  an 
indication  of  specific  mission  segments  producing  high  workload 
which  we  will  refer  to  as  operator  overload. 
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Develop  a  Teak  Lot 


Initially  Define  Jobe 


Initially  allocate 
Tasks  to  Jobs 


Define  Sequential 
Relationships  of  Tasks 


Execute  the 
Simulation 
Model 
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To  evaluate  overall  workload,  summary  descriptive 
statistics  will  be  presented  for  overall  mission  scenario 
workload  including  percentage  of  time  spent  at  different  workload 
levels  and  percentage  of  time  above  "critical”  workload  levels 
(with  critical  values  either  being  defined  by  the  analyst  or  by 
default  values) .  Analysts  will  also  be  given  the  opportunity  to 
define  workload  time  "windows"  representing  the  ability  of  the 
operator  to  spread  out  the  performance  of  tasks  during  high 
workload  situations. 

To  evaluate  specific  mission  segments  producing  high 
workload,  the  data  will  be  presented  in  several  ways.  First,  a 
time  line  analysis  will  be  developed  of  operator  workload 
throughout  each  mission  and  scenario  studied  on  the  following 
four  different  workload  channels: 

1.  visual 

2 .  auditory 

3 .  cognitive 

4 .  psychomotor 

Separate  analyses  will  be  produced  for  each  operator.  An 
example  of  one  of  these  analyses  is  presented  in  Figure  4. 

Graphic  overlays  will  be  prepared  by  the  aid  so  that  the  analyst 
can  determine  points  in  the  scenario  at  which  workload  is  high. 

Second,  the  analyst  will  be  given  the  opportunity  to  define 
"excessive"  workload  conditions  in  the  context  of  the  above  four 
types  of  workload  (we  will  define  these  workload  scales  in 
Section  3.2  of  this  paper).  The  analyst  will  be  able  to  specify 
critical  values  for  each  of  the  four  workload  categories  (visual, 
auditory,  cognitive,  and  psychomotor) ,  decision  logic,  and 
workload  window  sizes.  For  example,  the  analyst  could  ask  for 
all  points  at  which  "the  average  visual  workload  over  a  three 
second  period  exceeded  a  value  of  seven  and  the  cognitive 
workload  exceeds  a  value  of  four) .  Then,  the  WAA  would  present 
the  analyst  with  a  series  of  points  in  the  mission  at  which  this 
workload  threshold  is  exceeded.  These  points  would  be  defined  by 
mission  time  and  all  operator  activities  at  that  point  in  the 
missions. 

The  examination  of  these  outputs  will  be  facilitated  by  a 
set  of  guidelines  that  the  analyst  should  consider  in  determining 
when  workload  is  excessive.  These  guidelines  or  heuristics  will 
permit  the  analyst  to  determine  whether  or  not  workload 
throughout  the  mission  within  the  scenario  being  studied  is 
likely  to  exceed  operator  capacity.  Additionally,  the  analyst 
will  be  able  to  determine  the  points  at  which  this  overload  is 
expected  to  occur.  By  identifying  these  points  of  expected 
overload,  the  system  designers  will  be  able  to  either  1)  redesign 
the  system  to  reduce  workload  at  these  points,  2)  reallocate 
tasks  across  individuals  in  the  operating  crew,  3)  propose  the 
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addition  of  more  crew  members,  or  4)  define  research  to  be 
conducted  with  actual  human  operators  to  prove  that  the  system 
design  does  not  exceed  operator  workload  capacity. 

As  part  of  the  construction  of  the  operator  simulation 
network,  the  WAA  will  also  produce  estimates  of  the  task  times 
and  accuracies  associated  with  a  given  contractor  design.  In 
addition,  the  WAA  will  contain  a  sub-module  which  will  assist 
users  in  estimating  task  performance  based  on  system  design  in 
terms  of  time  and  accuracy.  The  task  performance  requirements 
will  be  derived  from  the  performance  requirements  set  for  higher 
level  mission  functions  in  Product  1.  This  same  sub-module  will 
also  compare  the  required  task  performance  to  the  estimated  task 
performance  and  identify  discrepancies. 

3.1.5  Automated  Components  for  the  WAA 

There  are  four  fundamental  types  of  software  which  will 
need  to  be  developed  to  support  the  WAA: 

1.  The  Templates  for  users  to  create  files  and  analyze 
results  of  the  analyses 

2.  The  Libraries  including  historical  information  which 
the  analyst  can  use  to  construct  an  analysis 

3 .  The  Files  which  the  user  creates  representing  the 
operator's  performance  within  a  mission 

4.  The  Models  to  run  the  operator  workload  simulation  and 
generate  data  for  analysis 


An  Applications  Manager  will  control  all  of  the  software 
elements.  This  will  be  the  operating  system  in  which  the  analyst 
works . 


Below  are  the  specific  software  elements  associated  with 
each  of  the  above  four  general  types  of  software: 

The  Templates 

1.  Function  and  Task  Definition  Template  -  This  program 
will  lead  the  analyst  through  the  creation  of  lists  of 
operator  functions  and  tasks  and  assist  the  analyst  in 
assigning  tasks  to  specific  operators  for  the  system 
being  studied.  It  will  include  definition  of  task 
performance  parameters,  workload  requirements,  and 
limitations  on  task  performance  (e.g.,  the 
availability  of  resources,  the  completion  of  other 
tasks) . 
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2.  The  Task  Performance  Parameter  Estimation  Template  - 
This  program  will  lead  the  analyst  through  the 
estimation  of  task  performance  parameters  via 
comparison  with  the  task  libraries,  use  of  motion-time 
estimation  techniques,  use  of  task  element  estimation 
techniques  (e.g.,  HOS) ,  or  subject-matter  expert 
estimation.  This  software  element  will  be  embedded  in 
the  Function  Task  Definition  Template,  but  it  is  of 
sufficient  importance  and  complexity  to  distinguish 
for  the  purposes  of  discussion  in  this  paper. 

3.  The  Scenario  Creation  Template  -  This  program  will 
lead  the  analyst  through  the  definition  of  scenarios 
under  which  the  system  will  be  studied.  It  will 
involve  the  development  of  sequencing  relationships 
among  operator  tasks  and  the  addition  of  non-operator 
tasks  (e.g.,  tactical  models)  should  these  system 
elements  need  to  be  modeled. 

4.  The  Workload  Diagnostics  Decision  Aid  Template  -  This 
program  will  assist  the  analyst  in  defining  high 
workload  for  the  simulation  data  analysis. 

Ultimately,  it  will  assist  the  analyst  in  determining 
whether  workload  was  excessive. 

5.  Task  Reallocation  Template  -  This  template  will  lead 
the  analyst  through  the  process  of  determining  task 
allocations  to  operators  to  assure  that  system 
performance  as  well  as  workload  is  satisfactory.  The 
focus  of  this  template  will  not  be  to  estimate  task 
performance  for  a  given  design  (this  is  the  job  of  the 
Task  Performance  Parameter  Estimation  Template) . 
Rather,  this  template  will  lead  the  analyst  through 
the  process  of  finding  acceptable  task  allocations 
from  an  operator  workload  perspective  for  the  design 
to  satisfy  the  performance  requirements  (identified  in 
Product  1)  while  staying  within  the  manpower 
constraints  (identified  in  Product  2). 

6.  Reports  Generator  Template  -  This  template  will  be 
similar  to  a  menu,  prompt,  and  command  driven 
relational  data  base  manager  that  is  WAA  specific.  It 
will  be  used  by  the  analyst  to  gain  access  to  and 
retrieve  data  from  the  Task  Data  File.  When  the 
analyst  has  identified  a  staffing  plan  that  meets 
system  performance  requirements,  does  not  violate 
manpower  constraints,  and  maintains  acceptable 
workload  levels  for  all  of  the  operators,  the  Reports 
Generator  will  produce  reports  of: 

•  the  operator  jobs  that  were  defined  for  that 
staffing  plan. 
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•  the  tasks  that  were  assigned  to  each  operator 
job. 

•  the  number  of  operators  needed  per  job. 

In  addition,  the  Reports  Generator  Template  will  let 
the  analyst  obtain  hard  copy  reports  of  the 
performance  parameters  and  workload  values  that  were 
assigned  to  operator  tasks  for  the  current  staffing 
plan. 

The  Libraries 


1.  Task  Library  -  This  file  will  include  historical  data 
on  operator  tasks  sorted  by  mission  area  and  function. 

2.  Scenario  Library  -  This  file  will  include  historical 
data  on  mission  scenarios  sorted  by  mission  area. 
Scenarios  represent  the  sequences  of  operator  tasks 
and  conditions  related  to  specific  mission  types. 

The  Files 


1.  Task  Data  File  -  This  file  will  include  all  data  which 
the  analyst  creates  defining  system  operator (s)  tasks 
within  each  function. 

2.  Scenario  Data  File  -  This  file  will  include  all  data 
which  the  analyst  created  regarding  specific  scenarios 
under  which  system  operation  will  be  studied. 

The  Models 


1.  The  Computer  Simulation  Model  -  This  program  will 
combine  the  task  and  scenario  data  files  and  run  a 
computer  simulation.  Output  of  this  simulation  will 
include  workload  levels  for  each  operator  at 
predefined  time  intervals  throughout  the  simulation 
(e.g.,  twice  a  second).  These  data  will  be  used  by 
the  workload  data  analysis  model. 

2.  The  Workload  Data  Analysis  Model  -  This  program  will 
allow  the  analyst  to  review  workload  data  generated  by 
the  computer  simulation.  It  will  permit  him  to  review 
points  in  the  mission  where  workload  was  excessive 
based  upon  whatever  definition  of  "excessive"  he 
chooses  to  use.  It  will  also  generate  all  outputs 
defined  in  Section  3.1.4. 
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3.1.6  Overview  of  Approach  for  Product  Development 

Virtually  all  of  this  aid  will  be  automated  with  the 
exception  of  some  basic  documentation  to  "get  the  analyst 
started."  Therefore,  let  us  discuss  product  development  in  the 
context  of  the  development  of  the  four  categories  of  software 
described  above. 

The  three  sets  of  software  which  will  need  to  be  developed 
as  part  of  product  development  are  the  Templates,  the  Libraries, 
and  the  Models.  The  fourth  set  of  software,  the  Files,  will  be 
created  by  analysts  as  they  use  the  WAA.  Let  us  briefly  discuss 
the  development  of  the  Templates,  Libraries,  and  Models 
individually.  More  detail  on  each  of  these  is  presented  in 
Section  5. 

The  Templates  -  As  we  stated  earlier,  the  underlying 
software  which  will  support  the  use  of  computer  simulation  is 
Micro  SAINT.  Micro  SAINT  currently  provides  a  model  development 
interface  which,  while  very  powerful,  is  also  very  general.  To 
train  analysts  to  use  the  current  model  development  software  for 
operator  workload  modeling  would  require  special  training  which 
is  undesirable. 

We  will  use  the  power  of  Micro  SAINT  model  execution  and 
data  generation  but  develop  specific  model  development  software 
aimed  directly  at  operator  workload  analysis.  Therefore,  rather 
than  a  general  model  development  interface  as  currently  exists, 
we  will  have  a  very  "WAA  specific"  interface.  This  will, 
necessarily,  sacrifice  some  of  the  power  of  the  general  Micro 
SAINT  tool  but  will  result  in  a  series  of  templates  which  are  far 
easier  for  the  analyst  to  learn  and  use. 

In  this  task,  we  have  identified  preliminary  user  steps  and 
user  interfaces.  We  emphasize  that  the  user  interfaces  are 
preliminary,  intended  more  to  illustrate  ideas  and  clarify  points 
than  to  provide  specific  interfaces.  In  Task  2  of  this  effort, 
we  will  develop  specific  user  scripts  which  will  be  submitted  to 
users  for  comments.  Additionally,  we  will  develop  data  flow 
diagrams  linking  user  interfaces  to  the  generation  of  the  Files 
which  will  be  used  in  the  analysis. 

The  Libraries  -  The  Libraries  will  be  discussed  in  some 
detail  in  Section  4.1  of  this  paper.  Specifically,  we  will 
discuss  the  types  of  data  which  will  be  required  to  feed  the 
analyses  which  will  be  conducted  in  the  operator  workload 
simulation  and  analysis.  In  Section  5.1,  we  will  discuss  the 
data  sources  for  initial  construction  of  these  libraries  as  well 
as  preliminarily  identifying  the  subset  of  mission  areas  for 
which  we  will  develop  libraries. 


El-52 


Our  basic  philosophy  for  developing  these  libraries  will  be 
to  construct  a  set  of  entries  into  the  library  during  Task  3  of 
this  effort.  This  set  will  be  selected  so  that  it  represents  the 
mission  areas  which  are  likely  to  require  MANPRINT  analyses  in 
the  near  future  based  on  existing  requirements.  Additionally,  we 
will  embed  mechanisms  into  the  software  for  adding  task  and 
scenario  files  to  the  libraries  as  users  conduct  MANPRINT 
analyses  on  new  systems.  In  doing  this,  analysts  will  be  able  to 
create  their  own  files  representing  a  new  system  and  then,  if 
appropriate,  add  that  file  to  the  library.  For  example,  as  a  new 
helicopter  is  developed,  the  analyst  using  the  WAA  to  analyze 
that  helicopter's  staffing  requirements  will  create  new  task  and 
scenario  files  which  are  unique  to  that  system.  At  some  point, 
this  analyst  would  be  given  the  opportunity  to  add  these  files 
into  the  library.  Then,  when  the  next  generation  helicopter  is 
being  considered,  the  analyst  conducting  the  MDA  analysis  could 
draw  from  the  libraries  the  most  appropriate  similar  system  (or 
pieces  from  several  systems,  for  that  matter) . 

In  essence,  we  propose  to  develop  enough  pieces  of  the 
library  to  bootstrap  the  use  of  this  tool.  Then,  as  the  aid  is 
used,  the  libraries  will  grow  reflecting  new  system  designs. 

This  concept  of  a  constantly  evolving  library  is  essential 
if  the  MDA  and  WAA  are  to  have  a  lifespan  of  more  than  one 
generation  of  weapon  systems.  Obviously,  if  this  is  to  be 
effective,  consideration  will  need  to  be  given  to  configuration 
management  issues.  These  will  also  be  discussed  in  Section  3.3 
of  this  paper. 

In  Task  2  of  this  effort  (development  of  detailed  design 
specifications),  we  will  develop  data  base  formats  (e.g.,  field 
definitions,  record  lengths)  as  well  as  software  for  the  creation 
and  management  of  these  libraries.  Additionally,  we  will  finally 
define  all  data  sources  for  the  specific  entries  into  the 
libraries  to  be  developed  in  Task  3  of  this  effort. 

Finally,  in  Task  3,  we  will  develop  the  library  management 
software  and  construct  the  subsets  of  the  libraries  defined  in 
Task  2. 

We  should  also  note  here  that  the  collection  of  the  data 
for  these  libraries  will  be  performed  in  coordination  with  the 
development  of  libraries  for  Product  1.  While  Product  1  itself 
is  intended  to  study  systems  without  considering  the  allocation 
of  tasks  to  components,  the  creation  of  the  Product  1  libraries 
will  necessarily  require  examination  of  performance  data  for 
specific  systems  and  the  components  (including  the  human)  within 
the  system.  Therefore,  the  data  collection  effort  for  Product  1 
will  be  performed  in  conjunction  with  the  data  collection  for 
Product  5.  In  fact,  in  many  cases,  the  data  will  simply  be 
stored  in  two  places. 
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The  Models  -  As  was  stated  in  the  discussion  of  Templates, 
the  basis  for  all  models  will  be  Micro  SAINT.  Again,  however, 
the  analyst  will  not  "see”  Micro  SAINT,  he  will  not  "execute" 
Micro  SAINT  models,  nor  will  he  "analyze"  Micro  SAINT  data  in  the 
ways  that  a  user  of  Micro  SAINT  would.  Rather,  by  creating  task 
files  and  scenario  files,  the  analyst  will  have  created  all  of 
the  information  for  the  simulation.  Our  modeling  software  will 
create  Micro  SAINT  models  directly  from  these  files,  execute 
them,  collect  the  appropriate  data,  and  then  analyze  the  data, 
all  in  the  specific  context  of  workload  analysis.  No  data  will 
be  required  of  the  analyst  that  is  not  needed  by  the  WAA  and  no 
spurious  data  analyses  will  be  presented  to  the  analyst  if  they 
do  not  directly  relate  to  operator  workload  analysis. 

In  this  task,  we  have  identified  high  level  flow  charts  for 
the  software  model  architecture.  In  Task  2  of  this  effort,  we 
will  develop  detailed  software  specifications  and,  in  fact,  we 
expect  to  be  able  to  begin  some  coding  within  the  available  time. 
Finally,  in  Task  3  we  will  complete  all  software  development, 
debugging,  and  operational  testing  of  the  models. 


3.2  Detailed  Discussion  of  the  Steps  Followed  Bv  the  Analyst 
Using  the  Workload  Assessment  Aid  (WAA) 

The  purpose  of  this  section  is  to  provide  a  detailed 
description  of  the  steps  that  the  analyst  will  perform  to  use  the 
WAA.  These  steps  were  outlined  briefly  in  Section  3.1.3. 

We  are  providing  the  detailed  discussion  of  the  WAA  from 
the  user's  perspective  before  we  present  the  discussion  of  the 
software  design  for  several  reasons.  First,  the  utility  of  the 
product  will  depend  largely  on  its  usability,  not  on  its 
architecture.  Second,  in  reviewing  this  concept  paper,  it  would 
be  difficult  to  understand  the  collective  purpose  of  the  software 
elements  by  simply  describing  the  elements.  This  would  be 
analogous  to  describing  an  automobile  to  someone  who  has  never 
used  one  by  describing  the  engine  and  tires  rather  than 
describing  how  and  why  it  is  driven.  By  first  describing  the  WAA 
from  the  user's  perspective  in  this  section  and  then  from  a 
software  perspective  in  the  next  section  we  are,  in  essence, 
describing  it  functionally  first  and  architecturally  second. 

Within  the  discussion  of  each  of  the  steps  outlined  briefly 
in  Section  3.1.3,  we  will  present  four  pieces  of  information. 
First,  we  will  provide  the  required  inputs  to  the  step.  Inputs 
are  separated  into  those  data  which  are  external  to  the  WAA  and 
those  data  which  are  internal  to  the  WAA.  Therefore,  a  data 
source  such  as  a  task  analysis  of  the  system  is  an  external  input 
whereas  a  library  which  is  part  of  the  WAA  itself  is  an  internal 
input.  Steps  can  create  outputs  which  are  inputs  to  succeeding 
steps. 


El-54 


Second,  we  will  define  the  processes  which  are  inherent  to 
the  step  from  the  perspective  of  the  analyst.  Some  of  these 
steps  will  involve  data  gathering  (e.g.,  collecting  the  inputs) 
and  some  will  involve  manipulation  of  the  data  and  analyses  using 
the  WAA. 

Third,  we  will  define  the  outputs  of  the  step.  These 
outputs  will  generally  be  either  data  which  are  used  in  ensuing 
steps  or  analyses  which  can  be  used  by  the  analyst  in  evaluating 
manpower  issues. 

Finally,  we  will  provide  some  examples  of  user  interfaces 
for  the  various  data  entry,  manipulation,  and  analyses  associated 
with  each  step.  Obviously,  these  are  not  final  interface 
designs.  Rather,  they  are  intended  to  provide  the  reviewer  with 
a  sense  of  the  types  of  interfaces  that  we  intend  to  build  into 
the  system. 

To  the  greatest  extent  possible,  we  have  gone  into  detail 
about  the  specific  actions  involved  in  performing  each  step. 
Readers  may  conclude  that  there  are  better  ways  of  performing 
these  steps  such  as  presenting  certain  information  differently, 
other  data  sources,  etc.  We  present  the  detail  not  because  we 
believe  it  is  the  "only  way  to  do  things"  but  because  it  will 
provide  the  reader  with  the  best  sense  of  our  approach  to 
providing  the  Army  analyst  with  a  tool  for  operator  manpower 
determination.  We  will,  of  course,  modify  the  tool  in  later 
stages  of  design  based  on  input  from  target  users  and  ARI. 

Overview 

In  testing  each  of  the  hypothetical  sets  of  task 
assignments  to  operators,  the  analyst  will  undertake  four  basic 
activities.  First,  the  analyst  will  create  the  Task  File  which 
will  include  all  information  associated  with  the  operator's 
activities  during  each  of  the  mission  scenarios  which  he  or  she 
decides  to  analyze.  This  Task  File  will  contain  all  of  the 
information  associated  with  each  operator  task  including 
performance  times,  accuracies,  and  workload  values.  Second,  the 
analyst  will  develop  scenarios  for  study.  These  scenarios  will 
include  those  which  are  projected  to  be  high  workload  scenarios. 
The  information  will  include  operator  task  sequencing  information 
as  well  as  models  of  other  aspects  of  the  system  that  the  analyst 
chooses  to  include  in  the  analysis  (e.g.,  the  tactical 
environment) .  Third,  the  analyst  will  run  the  computer  simulation 
and  collect  workload  data.  Fourth,  the  analyst  will  analyze  the 
data  from  the  simulation  and  determine  points  of  operator 
overload  as  well  as  potential  ways  to  alleviate  this  overload. 
Figure  7  is  a  flow  chart  of  these  basic  activities  for  hypothesis 
testing. 
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Figure  7.  Top  Level  Flow  Chart  of  the  Hypothesis  Testing  Approach 


El-  56 


In  Section  3.1.3,  we  outlined  eleven  specific  steps  that 
the  analyst  would  follow  to  perform  the  above  activities.  These 
steps  are  repeated  below: 

1.  Develop  a  list  of  the  tasks  in  the  system  design  that 
will  be  assigned  to  operators. 

2.  Define  all  crew  positions  (jobs). 

3.  Initially  assign  tasks  to  jobs. 

4.  For  each  mission  to  be  analyzed,  develop  sequential 
relationships  between  operator  tasks  (if  they  are  not 
included  specifically  in  the  task  analysis) . 

5.  Based  on  comparability  analysis,  motion-time 
estimation  techniques,  subject-matter  expert 
estimates,  or  HOS  modeling,  develop  performance  times 
and  accuracies  for  each  operator  task. 

6.  Assign  workload  values  to  each  operator  task  (one 
value  for  each  workload  channel  [i.e.,  visual, 
auditory,  cognitive,  and  psychomotor  workload]). 

7.  For  each  scenario  to  be  studied  within  each  mission, 
develop  descriptions  of  any  additional  environmental, 
tactical,  or  other  system  conditions  which  are  to  be 
included  in  the  analysis. 

8.  Exercise  the  computer  simulation  (which  will  be 
created  directly  from  files  generated  during  the  above 
seven  steps) .  This  simulation  will  be  exercised  for 
each  mission  type  and  each  scenario  within  a  mission 
type. 

9.  Review  the  output  of  the  computer  simulation ( s) . 

10.  Determine  acceptability  of  operator  staffing  plan  and, 
if  discrepancies  exist  between  required  operators  and 
available  operators,  define  the  points  at  which 
solutions  to  operator  overload  must  be  found. 

11.  Reallocate  tasks  to  jobs  or  add  operators  in  a  way 
that  would  result  in  successful  system  operation  and 
acceptable  operator  workload. 

Figure  8  provides  a  flow  chart  of  the  sequencing  of  the 
above  eleven  steps. 
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Steps  the  Analyst  will  Follow  in  Using  the  WAA. 


The  first  four  steps  are  analogous  to  a  task  analysis  of 
operator  activities.  The  process  that  the  analyst  will  go 
through  to  obtain  this  information  will  depend  largely  on  the 
availability  of  task  analysis  data  supplied  by  the  contractor  who 
is  submitting  the  design.  It  has  become  standard  practice  to 
include  operator  task  analysis  data  requirements  into  Requests 
for  Proposals  for  major  weapon  systems  (e.g. ,  LHX  Draft  RFP, 
November  1986).  Hovever,  it  is  not  yet  a  “sure  thing'1  that  a 
task  analysis  will  be  provided.  If  the  contractor  does  provide 
task  analysis  data,  there  is  no  guarantee  that  it  will  be 
sufficient  or  appropriate  for  this  analysis.  If  contractor  task 
analyses  are  unavailable,  the  analyst  will  essentially  need  to 
conduct  a  task  analysis  from  available  sources  of  information. 
These  first  four  steps  represent  the  development  of  the  analyst's 
initial  hypothesis  of  jobs,  tasks  per  job,  and  numbers  of 
operators  per  job. 

In  Steps  5,  6,  and  7,  the  analyst  will  use  the  WAA  to  enter 
information  that  will  eventually  be  used  to  simulate  the  workload 
requirements  and  performance  parameters  of  each  operator  in  the 
hypothesized  staffing  plan. 

Let  us  now  go  through  each  of  the  steps  and  discuss  in  some 
detail  1)  the  required  input  data  (both  internal  and  external 
including  data  sources) ,  2)  the  process  for  performing  the  step, 
3)  the  output  of  the  step,  and  4)  the  software  interfaces 
associated  with  the  system  software  for  performing  that  step. 

3.2.1  Step  1  -  Develop  a  list  of  tasks  in  the  system  design 

that  will  be  assigned  to  operators. 


Input 


External  input  -  The  primary  external  input  to  this  step  can 
come  from  a  variety  of  sources.  The  preferred  input  is  the 
design  documents  provided  to  the  government  by  the  contractor 
designing  the  system.  This  documentation  should  include  listings 
of  operator  tasks. 

Other  external  input  for  determining  an  operator  task  list 
will  be  Subject  Matter  Experts,  the  output  of  the  System 
Performance  Requirements  Estimation  Aid  (Product  1  of  this 
effort) ,  and  task  analyses  associated  with  the  predecessor  or 
other  comparable  existing  systems.  Detailed  data  on  the  tasks 
for  these  systems  are  available  in  the  Trainer's  Guides, 

Soldier's  Manuals,  Job  Books,  How-to-Fight  Manuals,  or  Operator's 
Manuals. 
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Internal  input  -  When  the  system  design  documents  don't 
identify  operator  tasks,  the  analyst  may  be  able  to  identify 
tasks  from  an  analogous  system  in  the  Task  Library.  These  tasks 
can  be  used  as  a  starting  point  for  developing  a  task  list  for 
the  system  being  evaluated. 

The  Process 


The  process  the  analyst  will  go  through  to  develop  a  list  of 
operator  tasks  depends  on  the  availability  and  source  of  data. 
Figure  9  provides  a  flow  chart  of  the  sub-steps  in  this  process. 

When  the  contractor  has  submitted  a  task  analysis  with  the 
design  documentation,  it  will  contain  a  list  of  tasks  that  have 
been  assigned  to  operators  of  the  system.  When  this  is  the  case, 
the  process  of  developing  a  task  list  is  relatively 
straightforward.  Other  than  physically  collecting  the  documents, 
the  analyst  just  needs  to  ensure  that  the  listed  tasks  are  at  a 
level  of  detail  that  will  facilitate  this  analysis.  While  the 
analysis  can  be  performed  at  any  level  of  task  detail,  the 
desired  level  of  detail  would  be  what  is  frequently  referred  to 
as  the  task  level  of  detail.  This  level  of  detail  is  somewhere 
above  the  button  pushing  and  switch  flipping  level  and  below  the 
major  function  level  such  as  M identify  present  location." 

If  the  task  detail  is  too  shallow,  the  analyst  has  the 
option  of  decomposing  the  tasks.  To  do  this  would  require  a 
detailed  task  analysis  (i.e.,  review  system  design,  interview 
subject  matter  experts,  etc.).  The  WAA  will  not  provide  the 
analyst  with  tools  to  do  this.  Rather,  it  will  provide  him  with 
his  alternatives  and  the  implications  of  each  which  are  as 
follows: 


Refine  the  task  analysis  -  This  will  permit  a  more 
accurate  workload  analysis  but  will  require  substantial 
work  on  the  part  of  the  analyst  (an  order  of  magnitude 
greater  than  that  required  to  use  the  rest  of  the  WAA) . 

Require  the  contractor  submitting  the  design  to  refine 
the  task  analysis  -  This  will  permit  a  more  accurate 
analysis  but  may  delay  the  conduct  of  the  analysis  and 
pose  logistical  problems. 

Conduct  the  workload  analysis  at  the  level  of  task 
definition  provided  -  This  will  result  in  a  less 
rigorous  analysis. 
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Figure  9.  Develop  Task  List 
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When  the  contractor  has  not  supplied  an  operator  task  list 
with  the  system  design,  the  analyst  will  begin  to  develop  a  task 

list  by  first  determining  whether  or  not  there  is  task  list  for  a 

comparable  system  in  the  Task  Library.  If  there  is  an  adequate 
comparable  system  in  the  Library,  the  analyst  will  use  that  list 
and  the  output  of  system  tasks  from  the  System  Performance 
Requirements  Estimation  Aid  (SPREA)  as  a  starting  point  for 
developing  a  task  list  for  the  new  system  design. 

When  the  Task  Library  does  not  contain  an  adequate 
comparable  system,  the  analyst  will  decide  whether  there  is  a 
comparable  fielded  system  that  is  not  in  the  Task  Library.  Task 

data  for  fielded  systems  that  are  not  in  the  Task  Library  can  be 

found  in  Trainer's  Guides,  Soldier's  Manuals,  Job  Books,  How-to- 
Fight  Manuals,  or  Operator's  Manuals. 

When  the  analyst  has  obtained  a  task  list  from  a  comparable 
system,  he  or  she  will  compare  each  operator  task  in  the 
comparable  system  with  the  tasks  from  Product  1  and  with  the 
system  design  to  determine  if  it  is  an  operator  task  in  the  new 
system.  When  the  analyst  has  developed  a  preliminary  task  list 
using  this  comparable  system  approach,  it  should  be  reviewed  and 
verified  by  a  subject  matter  expert. 

When  the  system  under  evaluation  is  so  radically  different 
from  anything  currently  in  the  field  that  it  is  not  possible  to 
find  an  adequate  comparable  system  and  an  operator  task  list  was 
not  submitted  with  the  system  design,  the  analyst  may  be  able  to 
develop  an  operator  task  list  solely  from  the  output  of  the 
SPREA,  the  system  design,  and  the  assistance  of  a  subject  matter 
expert. 

Output 

The  output  of  this  step  will  be  a  listing  of  tasks  which  are 
required  for  operation  of  the  system  under  study. 

Sample  User  Interfaces 

Because  this  is  largely  a  data  gathering  phase,  there  will 
be  little  direct  interaction  with  the  system.  The  exception  to 
this  will  be  some  software  that  will  allow  the  analyst  to  search 
through  the  Task  Library  for  operator  tasks  for  systems  that  are 
comparable  to  the  system  under  study.  The  tasks  that  are  stored 
in  the  Task  Library  are  sorted  and  categorized  by  mission  area, 
major  system  type,  and  function.  The  analyst  will  be  able  to 
search  for  and  select  a  comparable  system  task  list  by  converging 
on  that  system  through  a  series  of  menus.  For  example,  when  the 
analyst  gains  access  to  the  Task  Library  and  selects  from  a  menu 
to  obtain  a  task  listing,  he  or  she  will  be  presented  with  a  menu 
of  mission  areas  that  are  included  in  the  library.  When  the 
analyst  selects  a  mission  area,  another  menu  will  display  a  list 
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of  the  major  systems  in  the  library  for  that  mission  area.  If 
this  menu  contains  a  system  that  is  similar  to  the  one  under 
evaluation  that  the  analyst  wants  to  use  for  comparison  with  the 
new  system,  he  or  she  can  obtain  a  printed  list  of  operator  tasks 
for  that  system.  This  list  of  tasks  will  be  organized  according 
to  the  crew  position  (job)  that  will  perform  the  task.  This 
breakdown  of  task  by  job  may  be  useful  to  the  analyst  when  he  or 
she  is  defining  crew  positions  for  the  system  under  study. 

In  addition  to  the  user  interfaces  for  searching  and 
selecting  task  lists  from  the  Task  Library,  there  will  be  some 
decision  aiding  software  embedded  within  the  system  to  aid  the 
analyst  in  determining  whether  the  contractor  supplied  task 
analysis  is  at  the  desired  level  of  detail.  These  interfaces 
will  be  of  a  ’'question  and  answer  with  examples"  nature  such  as 
that  presented  in  Figure  10. 

3.2.2  Step  2  -  Define  All  Crew  Positions 


Input 

External  Input  -  There  are  potentially  several  sources  of 
external  input  for  this  step.  The  preferred  source  is  a  document 
prepared  by  the  contractor  designing  the  system  describing  the 
crew  station  and  all  operator  duty  positions.  Duty  position 
assignments  for  predecessor  or  other  comparable  systems  are 
available  in  Job  Books,  Operator's  Manuals,  How-to-Fight  Manuals, 
and  from  available  ARTEP  data. 

Internal  Input  -  If  the  task  listing  data  collected  in  Step 
1  was  obtained  from  the  Task  Library,  those  tasks  are  organized 
by  operator  job. 

Process 


The  process  that  the  analyst  will  follow  to  initially  define 
operator  jobs  depends  on  the  source  of  information  available  to 
the  analyst.  Figure  11  provides  a  flow  chart  of  the  sub-steps  in 
this  process. 

If  the  contractor  conducted  a  task  analysis  and  has 
submitted  a  staffing  plan  with  the  system  design,  the  analyst 
will  use  the  contractor's  definition  of  operator  jobs  for  the 
initial  analysis. 
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Sample  User  Interface  to  Assist  the  Analyst 
In  Determining  the  Appropriate  Level  of  Task  Detail 

Note:  Bold  Entry  indicates  Analyst  Input 


To  start  this  analysis,  you  should  have,  in  hand,  the  operator 
task  analysis  from  which  you  will  be  working.  Is  this  available 
(type  yes  or  no)?  Yes 

This  analysis  will  help  you  to  determine  whether  the  task 
analysis  that  you  have  to  conduct  the  operator  workload  analysis 
is  at  a  desired  level  of  detail.  You  can  begin  this  analysis  by 
going  through  the  Task  analysis  and  selecting  tasks  which 
represent  the  following  levels  of  detail: 

1.  The  most  detailed  task  description  (i.e.,  the  one 
that  represents  the  most  detailed  level  of 
operator  task  definition.  For  example,  "push  the 
button"  is  more  detailed  than  "engage  the 
target . " ) 

2.  A  task  that  represents  an  "average"  level  of 
detail  (take  a  quick  look  —  don't  labor  over  the 
decision) 

3 .  The  least  detailed  task  description 


When  you  have  these  available,  you  can  begin  answering  the 
following  questions: 

1.  Is  the  lowest  level  of  detail  task  at  or  below  the 
"push  button,"  "flip  switch",  or  whatever  would  be 
analogous  for  your  system  level?  No 

2.  Is  the  lowest  level  of  task  detail  at  least  the 
operator  function  level  (e.g.,  "engage  enemy 
target")?  Yes 


Figure  10.  Sample  User  Interface  to  Assist  the  Analyst  in 
Determining  the  Appropriate  Level  of  Task  Detail 
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Defi  mtion 


Figure  11.  Define  All  Crew  Positions. 
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When  the  contractor  does  not  define  the  crew  positions  for 
the  system  design,  the  analyst  will  begin  to  develop  a  definition 
of  crew  positions  by  determining  whether  there  is  an  existing 
system  that  is  suitable  for  comparison  with  the  system  under 
evaluation.  If  the  task  listing  that  was  developed  in  Step  1  was 
obtained  from  a  system  in  the  Task  Library  that  was  comparable  to 
the  system  being  evaluated,  those  tasks  were  organized  by  crew 
position.  The  analyst  can  use  these  definitions  as  a  starting 
point  for  defining  operator  jobs  for  the  new  system. 

Duty  position  assignments  for  predecessor  or  other 
comparable  systems  that  are  not  in  the  Task  Library  are  available 
in  Job  Books,  Operator's  Manuals,  How-to-Fight  Manuals,  and  from 
available  ARTEP  data. 

When  operator  jobs  have  been  identified  for  a  comparable 
system  as  a  starting  point  for  defining  jobs  for  the  new  system 
design,  the  analyst  will  need  to  examine  the  new  design  to 
determine  whether  it  will  support  all  of  the  comparable  system 
jobs.  The  reason  for  this  is  that,  even  though  the  tasks  that 
must  be  performed  to  operate  the  new  system  may  be  very  similar 
to  those  in  the  comparable  system,  the  new  design  could  have 
eliminated  one  or  more  operator  workstations.  If  the  new  design 
will  not  support  all  of  the  jobs  that  were  included  in  the 
comparable  system,  the  analyst  will  need  to  get  assistance  from  a 
subject  matter  expert  to  revise  the  definition  of  crew  positions. 
The  analyst  will  also  need  to  take  into  consideration  the 
manpower  constraints  that  were  established  as  an  output  of 
Product  2  of  this  effort. 

When  the  contractor  does  not  define  the  operator  jobs  for 
the  new  system  design  and  there  is  no  existing  system  that  is 
adequate  for  use  as  a  comparable  system,  the  analyst  will  use  the 
new  system  design  and  the  assistance  of  a  subject  matter  expert 
to  define  operator  jobs. 

Outputs 

The  output  from  Step  2  will  be  the  computerized  Task  Data 
File  that,  at  this  point,  will  contain  only  the  job  titles  and 
job  descriptions  for  each  operator  in  the  initial  staffing  plan. 

Sample  User  Interfaces 

Figure  12  illustrates  a  sample  user  interface  for  entering 
operator  job  titles  and  job  descriptions  into  the  Task  Data  File. 
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Sample  User  Interface  to  Assist  the  Analyst 
In  Describing  Operator  Jobs 


Note:  Bold  Entry  indicates  Analyst  Input 


(1)  Operator  job  title:  M60  Tank  Commander 

(2)  Operator  job  description:  The  tank  commander  is 

responsible  for  all  tank  crew 
member  activities.  His 
primary  operational 
responsibility  is  to  watch  for 
targets  and  alert  the  crew  to 
engage  them  immediately. 

Type  the  number  of  the  field  you  want  to  change  (q  when  you  are 
done) 


Figure  12.  Sample  User  Interface  to  Assist  the  Analyst  in 
Entering  Job  Titles  and  Job  Descriptions. 


El-67 


3.2.3  Step  3  -  Initially  allocate  tasks  to  jobs. 


Inputs 

External  inputs  -  If  it  is  available,  the  preferred  input 
for  this  step  is  a  contractor  developed  operator  staffing  plan 
that  allocates  each  of  the  operator  tasks  to  a  duty  position  or 
job.  . 


Other  external  input  may  be  obtained  from  subject  matter 
experts  and  from  Army  manuals,  Job  Books,  and  task  analysis  data 
for  comparable  or  predecessor  systems. 

Internal  inputs  -  The  task  listing  that  was  an  output  of 
Step  1  and  the  Task  Data  File  that  was  created  as  an  output  of 
Step  2 . 

Process 


The  process  that  the  analyst  will  go  through  to  make  an 
initial  assignment  of  operator  tasks  to  crew  positions  will 
depend  on  the  source  and  availability  of  task  analysis  data  to 
the  analyst.  Figure  13  provides  a  flow  chart  of  the  sub-steps 
involved  in  this  process. 

If  the  contractor  has  submitted  a  staffing  plan  with  the 
system  design  that  indicates  task  assignments  to  duty  positions, 
the  analyst  will  use  that  set  of  assignments  as  a  starting  point 
for  the  initial  analysis. 

When  the  analyst  has  used  comparable  system  data  to  develop 
the  task  listing  and  crew  position  definitions,  he  or  she  will 
also  use  the  assignment  of  tasks  to  jobs  in  those  comparable 
systems  as  a  starting  point  for  assigning  tasks  to  jobs  in  the 
new  system. 

When  the  operator  task  listing  and  the  definition  of  crew 
positions  was  accomplished  directly  from  the  system  design  and 
subject  matter  expert  input  without  the  aid  of  a  contractor 
developed  staffing  plan  or  comparable  system  data,  the  analyst 
will  have  to  use  those  sources  to  initially  assign  tasks  to  jobs. 

For  each  potential  task  assignment  to  a  crew  position, 
whether  it  be  with  the  aid  of  a  contractor  supported  staffing 
plan  or  comparable  system  data,  the  analyst  will  need  to  examine 
the  proposed  system  design  to  ensure  that  it  will  support  that 
task  assignment  in  terms  of  giving  the  operator  access  to 
controls,  displays,  and  other  equipment.  When  the  design  will 
not  allow  a  task  to  be  assigned  to  an  operator  due  to  location  of 
equipment  or  other  operator  interface  constraints,  the  analyst 
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Use  Contractor's 
Task  Assignment  for 
Initial  Analysis 


Figure  13.  Initially  Allocate  Tasks  to  Jobs. 


will  need  to  reallocate  that  task  to  another  operator.  This 
reallocation  may  require  input  from  a  subject  matter  expert. 

The  information  that  will  be  required  for  each  task  will,  at 
this  point,  simply  be  task  titles  and  descriptions.  Descriptions 
will  always  be  optional. 

Output 

The  output  of  Step  3  will  be  a  Task  Data  File  that  includes 
an  initial  assignment  of  all  identified  operator  tasks  to 
specified  crew  positions  or  jobs.  At  this  point  in  the  analysis, 
the  Task  Data  File  will  not  yet  contain  task  performance 
parameter  estimates. 

Sample  User  Interfaces 

Figures  14  and  15  illustrate  sample  user  interfaces  that 
will  assist  the  analyst  in  assigning  tasks  to  operator  jobs  and 
entering  task  descriptions  into  the  Task  Data  File. 

3.2.4 _ Step  4  -  For  each  mission  to  be  analyzed,  develop 

sequential  relationships  between  operator  tasks 


Inputs 

External  Input  -  Step  4  will  have  as  input  the  mission  area 
analyses,  the  mission  simulation  models  developed  in  Product  1, 
the  system  O&O  Plan  with  operational  mode  summary,  MAA  and  MADP 
results,  the  contractor  trade  studies  examining  operator  workload 
(if  any  have  been  conducted) ,  and  subject  matter  expertise  as 
required  to  supplement  these  analyses. 

Task  sequence  information  from  the  predecessor  or  other 
comparable  systems  may  also  be  useful.  Such  information  is 
available  in  Soldier's  Manuals,  Job  Books,  Operator's  Manuals, 
and  ARTEP  data. 

Internal  Input  -  The  Task  Data  File  created  in  Step  3  and 
the  Mission  Scenario  Library. 
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Sample  User  Interface  to  Assist  the  Analyst 
In  Assigning  Tasks  to  Operator  Jobs 


Note:  Bold  Entry  indicates  Analyst  Input 


(1)  Operator  job  title  -  Tank  Commander 
Mission  Area  -  Armor 

System  type  -  M60 

(2)  List  of  operator  tasks  already  assigned  to  this  operator 
job: 


site  selection 
target  acquisition 
lay  the  gun 

call  "gunner,  ammo,  target" 


Type 


1  to  change  the  operator  on  which  you  are  working 

2  to  add,  modify,  or  delete  tasks  from  the  operator  task 

list 

3  to  review  more  tasks  from  the  task  file 

4  to  review  more  tasks  from  the  task  library 


Figure  14.  Sample  User  Interface  to  Assist  the  Analyst 
In  Assigning  Tasks  to  Operator  Jobs 
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Sample  User  Interface  to  Assist  the  Analyst 
In  Entering  Tasks  into  the  Task  Data  File 


Note:  Bold  Entry  indicates  Analyst  Input 


(1)  Task  title:  Ammo  selection 

(2)  Mission  area:  Armor 

(3)  System  type:  M60  Tank 

(4)  Task  description:  Depending  upon  the  target  type, 

distance,  and  environmental 
conditions,  the  type  of  ammo  to  be 
fired  at  the  target  must  be 
selected. 


Type  1,  2,  3,  or  4  to  change  any  of  the  above  fields 

5  to  review  the  task  performance  parameters  associated  with 
task 

6  to  review  other  tasks  from  the  task  library 


Figure  15.  Sample  User  Interface  to  Assist  the  Analyst  In 
Entering  Tasks  into  the  Task  Data  File. 
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Process 

The  purpose  of  this  step  is  for  the  analyst  to  link  the 
tasks  which  will  have  been  identified  in  the  previous  step.  To 
accomplish  this,  two  major  substeps  must  be  undertaken: 

1.  Identify  scenarios 

2.  Define  sequential  relationships  among  operator  tasks 


Let  us  discuss  each  of  these  substeps  individually. 

Identify  Scenarios  -  At  this  point  in  the  process,  the 
analyst  must  become  familiar  with  the  scenarios  for  which  he 
would  like  to  study  operator  workload.  Workload  cannot  be 
studied  from  a  purely  operator  or  hardware  and  software  system 
perspective  since  one  cannot  look  at  a  system  design  and  conclude 
whether  it  will  require  more  workload  than  an  operator  can 
manage.  Rather,  operator  workload  must  be  studied  in  the  context 
of  the  operational  environment.  In  a  military  environment,  this 
translates  to  the  identification  of  the  mission  scenarios. 

Obviously,  not  all  mission  scenarios  can  be  studied  for  a 
particular  system.  Every  system  can  be  involved  in,  essentially, 
an  infinite  number  of  scenarios.  Therefore,  the  analyst  will 
need  to  carefully  select  the  scenarios  in  which  operator  workload 
is  expected  to  be  the  limiting  factor. 

The  first  goal  in  this  step,  therefore,  is  to  determine  the 
probable  high-workload  missions  and  mission  segments.  There  will 
be  several  sources  of  data  to  which  the  analyst  will  be  led  by 
the  WAA,  including  the  Operational  Mode  Summary,  Mission  Profile 
in  the  O&O  Plan,  the  threat  description  in  this  and  other 
documents,  and  the  TRADOC  standardized  scenario  descriptions 
(SCORES) . 

As  part  of  the  MANPRINT  analysis  for  most  future  weapon 
systems,  workload  analyses  will  need  to  be  performed  (e.g.,  LHX 
Draft  RFP,  November  1986) .  Therefore,  as  part  of  the  contractor 
input  being  evaluated  wit1  the  WAA,  a  workload  analysis  may  be 
available.  In  this  workload  analysis,  high  workload  mission 
segments  and  scenarios  will  be  identified.  These  analyses  can 
serve  as  starting  points. 

However,  consistent  with  the  philosophy  that  we  will  be 
conducting  an  independent  analysis  of  contractor  conclusions,  not 
simply  relying  on  contractor  data,  this  analysis  should  be 
reviewed  by  subject  matter  experts  to  verify  that  these  are 
expected  to  be  the  highest  workload  mission  segments. 
Additionally,  the  subject  matter  experts  should  then  prioritize 
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the  mission  segments  in  the  order  of  those  with  the  highest 
expected  workload,  since  it  will  not  always  be  possible  to  study 
all  high  workload  mission  segments. 

In  most  cases,  the  contractors  will  not  have  conducted 
workload  analyses  as  part  of  the  trade  studies.  This  being  the 
case,  the  subject  matter  expert  will  need  to  provide  input  as  to 
the  most  likely  high  workload  mission  segments. 

Finally,  the  analyst  will  need  to  refer  to  the  mission  area 
analysis  to  develop  an  understanding  of  the  specific  tactical  and 
environmental  conditions  in  which  the  system  will  operate.  To 
the  greatest  extent  possible,  the  following  should  be  identified 
as  they  relate  to  each  of  the  mission  segments  identified  by  the 
subject  matter  experts: 

1.  Threat  and  target  types 

2.  Maximum  threat  and  target  density 

3.  Stressful  environmental  conditions 

4.  Climate,  terrain,  and  other  induced  stressors 


Develop  Sequential  Relationships  among  Operator  Tasks  -  In 
this  si’bstep,  the  analyst  must  translate  the  scenarios  developed 
in  the  previous  substep  into  groups  and  sequences  of  tasks  which 
the  operator  must  perform.  Three  elements  must  be  defined:  1) 
the  set  of  tasks  which  must  be  performed,  2)  the  order  in  which 
the  tasks  must  be  performed,  and  3)  the  conditions  controlling 
task  performance. 

The  primary  aid  presented  to  the  analyst  will  be  access  to 
the  Mission  Scenario  Library.  The  Mission  Scenario  Library 
(which  will  be  discussed  in  greater  detail  in  Section  3.3)  will 
include  sets  of  tasks  from  previous  systems  organized  by  mission 
segment  within  system  type  within  mission  area  (e.g.,  armor- 
attack  mission  segment  within  attack  helicopter  system  within  the 
aviation  mission  area) . 

The  analyst,  at  a  workstation,  will  begin  the  analysis  with 
the  highest  workload  mission  segments  identified  in  the  previous 
substep.  He  would  then  call  up  the  “Review  Mission  Scenarios" 
portion  of  the  software  from  the  Application  Manager.  The 
analyst  will  then  identify  the  mission  area  and  the  general 
system  type  from  a  series  of  menus.  If  the  system  is  truly 
unique  or  the  similar  systems  have  not  been  included  in  the 
library,  then  he  may  have  to  construct  the  mission  scenarios  from 
scratch. 
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If  he  or  she  can  identify  an  analogous  system  type,  the 
analyst  will  be  given  a  list  of  mission  scenarios  which  currently 
reside  in  the  library  for  that  system.  The  list  will  be  a  set  of 
scenario  titles.  As  the  analyst  finds  scenarios  which  he 
believes  are  analogous  to  those  he  or  she  wishes  to  study,  he 
will  be  able  to  review  detailed  descriptions  of  the  scenarios  in 
any  of  the  following  forms: 

1.  One-page  descriptions  of  the  scenario 

2.  Drawings  of  the  sequencing  of  tasks  in  the  scenarios 

3.  Detailed  descriptions  of  each  of  the  tasks  within 
the  scenarios 

An  example  of  each  of  the  above  three  types  of  information 
is  presented  in  Figures  16,  17,  and  18,  respectively.  These 
displays  will  be  presented  on-line  at  the  analyst's  workstation 
or  in  hard  copy. 

Based  on  these  reviews  the  analyst  should  be  able  to 
determine  which,  if  any,  of  the  scenarios  in  the  library  are 
appropriate. 

If  none  of  the  available  scenarios  are  appropriate,  then  the 
analyst  will  have  to  construct  task  sequencing  relationships  from 
scratch.  To  facilitate  this,  the  WAA  will  provide  an  on-line 
tutorial  of  the  types  of  data  that  will  need  to  be  collected  in 
order  to  construct  the  sequencing  relationships.  The  primary 
data  source  will,  necessarily,  be  subject  matter  experts.  More 
detailed  analysis  will  most  likely  be  beyond  the  available  time 
limitations  on  the  analyst  at  this  point  and  the  additional 
information  quality  would  probably  not  result  in  a  commensurate 
improvement  in  workload  prediction. 

As  the  analyst  reviews  the  analogous  scenarios,  he  will 
begin  constructing  his  particular  scenario.  Recall  that  the 
tasks  in  the  system  under  study  may  not  exactly  match  the  tasks 
in  the  analogous  scenario.  Likewise,  the  analogous  scenario 
itself  may  not  exactly  match.  Therefore,  some  interpretation  on 
the  part  of  the  analyst  will  be  required.  This  interpretation 
will  require  the  following  decisions: 

1.  How  do  the  tasks  in  the  analogous  scenario  compare  to 
those  defined  in  the  system  under  study?  -  Different 
levels  of  task  decomposition  and  different  system 
designs  could  affect  both  the  degree  of  task  similarity 
and,  therefore,  the  appropriateness  of  the  analogous 
scenario. 
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Sample  One  Page  Scenario  Description 


(1)  Scenario  Title  -  Anti  Armor  Engagement 

(2)  Mission  Area  -  Aviation 

(3)  System  type  -  Apache  helicopter 

(4)  Scenario  description: 

This  scenario  begins  at  the  entry  of  the  aircraft  into 
the  hover  zone  below  tree  level  where  threats  are  known 
to  be  (the  actual  number  of  threats  may  vary) .  Weather 
conditions  are  VFR.  The  helicopter  pops  up  to  acquire 
the  targets  and  then  pops  down  to  prioritize  the 
targets.  Then,  the  helicopter  begins  a  series  of  pop 
ups,  engage  targets,  pop  downs,  change  positions,  until 
all  targets  have  been  engaged  or  all  weapons  are 
expended.  At  this  point,  the  helicopter  pops  up  for 
battle  damage  assessment  and  leaves  the  area  (end  of 
scenario) 


Figure  16.  Sample  One  Page  Scenario  Description. 
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APACHE 


Figure  17.  Scenario  Diagram 


E 


Detailed  Description  of  Tasks  within  Scenarios 


Note:  Bold  Entry  indicates  Analyst  Input 


Scenario  title  -  Tank  one-on-one  engagement 


(1)  Task  title:  Ammo  selection 

(2)  Mission  area:  Armor 

(3)  System  type:  M60  Tank 

(4)  Task  description:  Depending  upon  the  target  type, 

distance,  and  environmental 
conditions,  the  type  of  ammo  to  be 
fired  at  the  target  must  be 
selected. 


Type  1,  2,  3,  or  4  to  change  any  of  the  above  fields 

5  to  review  the  task  performance  parameters  associated  with 

this  task 

6  to  review  other  tasks  from  the  task  library 


Figure  18.  Description  of  Tasks  Within  Scenarios. 
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2.  Is  the  inherent  sequencing  of  tasks  fundamentally  the 
same  for  the  new  system?  -  Inherent  sequencing,  defined 
as  the  sequential  relationships  among  tasks  which  are 
independent  of  operating  conditions,  will  often  differ 
as  a  function  of  the  new  system  design.  Some  tasks  may 
not  exist  for  the  operator  because  they  have  been 
automated,  others  may  be  fundamentally  different. 

3.  Is  the  conditional  sequencing  of  the  tasks  the  same  for 
the  new  system?  Conditional  sequencing,  defined  as  the 
way  that  task  sequencing  is  driven  by  conditions  of 
operation,  may  differ.  We  do  not  expect  detailed 
dynamic  models  of  operator  task  sequencing  to  be 
included  in  the  WAA  (e.g.,  models  that  consider  system 
reaction  to  threat  sensing  if  no  human  performance  is 
involved) .  Recall  that  the  purpose  of  the  WAA  is 
operator  workload  analysis,  not  system  simulation. 
However,  when  closed-loop  aspects  of  operator  behavior 
are  germane  to  workload,  then  some  modeling  of  these 
aspects  of  the  system  may  be  included.  However, 
operator  reactions  to  different  operating  conditions  may 
be  different  from  system  to  system  and  these  differences 
will  need  to  be  recognized. 

:he  analysts  will  make  these  comparisons  of  the  library 
scenario  to  the  set  of  task  sequences  they  must  create  by  moving 
between  or  displaying  simultaneously  six  windows  (they  will  be 
able  to  display  up  to  two  windows  simultaneously)  -  three  windows 
as  described  above  (summaries  of  the  scenario,  drawings  of  the 
task  sequencing,  or  detailed  task  descriptions)  defining  the 
system  they  are  developing  and  the  same  three  windows  describing 
the  library  scenario.  The  nature  each  of  these  windows  was 
previously  presented  in  Figures  16  through  18. 

Outputs 

Through  this  interactive  process,  sequences  of  tasks  and  the 
definition  of  how  their  performance  is  mitigated  by  conditions 
wi]l  be  defined.  In  doing  this,  the  analyst  will  have  provided 
the  data  required  for  a  computer  simulation  of  operator  behavior. 
The  next  step  will  be  to  assign  performance  parameters  to  tasks. 

Sample  User  Interfaces 

Interfaces  for  defining  task  sequencing  which  is  unique  to 
the  system  under  study  are  presented  in  Figures  19  and  20  for 
inherent  sequencing  differences  and  conditional  sequencing, 
respectively. 
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Sample  User  Interface  for  the  Definition  of  Inherent  Sequencing 


Note:  Bold  Entry  indicates  Analyst  Input 


(0) 

Scenario  title 

-  Tank  one-on-one  engagement 

(1) 

Task  title: 

Ammo  selection 

(2) 

Mission  area: 

Armor 

(3) 

System  type: 

M60  Tank 

(4) 

Operator: 

Tank  commander 

(5) 

Possible  following  tasks 

type 


(6)  Decision 


a.  Select  heat  seeking  missile 

b.  Select  Machine  guns 

C.  Cease  engagement 


Tactical 

Tactical 

Probabilistic 


Enter  0  to  change  the  scenario  on  which  you  are  working 

1,  2,  3,  or  4  to  change  the  task  on  which  you  are 
working 

5  to  change  information  on  the  task  sequencing 


Figure  19.  Defining  Inherent  Sequencing. 
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Sample  User  Interface  for  the  Definition  of 
Conditional  Sequencing 

Note:  Bold  Entry  indicates  Analyst  Input 

(0)  Scenario  title  -  Tank  one-on-one  engagement 

(1)  Task  *title:  Ammo  selection 

(2)  Mission  area:  Armor 

(3)  System  type:  M60  Tank 

(4)  Operator:  Tank  commander 


Possible  following  tasks  (6) 

Decision  type 

(7)  Decision 

Variable 

a.  Select  heat  seeking 

missile 

Tactical 

THREATYPE 

b.  Select  Machine  guns 

Tactical 

THREATYPE 

C.  Cease  engagement 

Probabilistic 

.95 

Enter  0  to  change  the  scenario  on  which  you  are  working 

1,  2,  3,  or  4  to  change  the  task  on  which  you  are 
working 

5  or  6  to  change  the  inherent  task  sequencing 
7  to  change  the  conditions  of  sequencing 

?  7 

Enter  the  letter  corresponding  to  the  decision  you  want  to  work 
on 
?  a 

The  following  expression  describes  when  the  operator  will  select 
this  course  of  action:  Select  heat  seeking  missile 
IF  THREATYPE  ==  MOBILE  OR  THREAT 

Type  in  a  new  expression  or  type  'm'  to  change  this  expression 

Figure  20.  Defining  Conditional  Sequencing. 
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3.2.5 


Step  5  -  Based  on  comparability  analysis,  motion-time 
estimation  techniques,  subject-matter  expert  estimates, 
or  HOS  modeling,  compute  performance  times  for  each 
operator  task 


Inputs 

External  Input  -  The  contractor's  design  document, 
particularly  the  portion  describing  the  user  interface  will  be 
the  primary  input.  Also,  subject  matter  experts  may  be  required. 

Internal  Input  -  The  output  of  Step  3,  the  Task  Data  File, 
will  be  the  main  input  (it  is  the  Task  Data  File  which  we  will  be 
augmenting  in  this  step) .  Also,  the  Task  Library  will  be  used. 

Process 


„  Step  5  will  require  the  analyst  to  estimate  parameters 
associated  with  operator  task  performance  for  each  of  the  tasks 
identified  in  Step  1  and  added  to  the  Task  Data  File  in  Step  3. 
The  parameters  which  will  need  to  be  identified  will  include  the 
following: 

1.  Mean  task  performance  time 

2 .  Standard  deviation  of  task  performance  time 

3.  Probability  of  making  an  error  in  the  task  and, 
therefore,  forcing  the  task  to  be  re-performed 

All  of  these  parameter  estimates  will  represent  expected 
values  under  the  stated  operating  conditions  for  an  operator  with 
the  personnel  characteristics  and  training  equal  to  the 
constraint  values  determined  by  the  PCEA  and  TCEA,  respectively. 

Step  5  will,  in  many  ways,  be  similar  to  Step  4  in  that  the 
analyst  will  examine  the  Task  Library  to  determine  whether 
analogous  tasks  can  be  found  from  earlier  systems  for  each 
operator  task  in  the  Task  Data  File.  If  these  analogous  tasks 
exist,  then  the  analyst  can  use  their  task  performance  parameters 
to  set  those  parameters  in  the  new  system  operator  tasks. 

If  analogous  tasks  do  not  exist  in  the  Task  Library,  then 
the  analyst  will  be  provided  with  some  fairly  powerful  tools  for 
estimating  task  performance  time  should  he  choose  to  use  them. 

In  addition  to  the  Task  Library  and  the  obvious  alternative, 
subject  matter  expert  opinions,  we  will  provide  two  additional 
tools,  motion-time  study  methods  (for  motor-intensive  tasks)  and 
HOS  task  time  estimation  methods  (for  information  processing- 
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intensive  tas>  3)  .  The  software  to  lead  the  analyst  through  the 
application  of  these  routines  will  be  embedded  within  the  Task 
Definition  Template  of  the  WAA.  The  details  of  this  software 
will  be  presented  in  Section  3.3. 

When  analogous  tasks  exist  in  the  Task  Library  -  When 
analogous  tasks  exist,  the  analyst  pei forming  this  step  will 
follow  steps  virtually  identical  to  those  that  were  followed  in 
the  previous  step.  He  or  she  will  review  listings  from  the  Task 
Library  by  examining  tasks  from  similar  mission  segments  within 
system  types  within  mission  areas.  Then,  through  the  use  of  a 
windowing  technique  similar  to  that  described  in  Step  4,  the 
analyst  will  examine  the  analogous  task  from  the  Task  Library  and 
decide  if  it  is  sufficiently  similar  to  the  task  from  the  system 
being  studied.  When  the  analyst  finds  one  that  is  sufficiently 
similar,  all  task  parameters  will  be  copied  from  the  task  in  the 
Task  Library  to  that  in  the  Task  Data  File. 

When  analogous  tasks  do  not  exist  -  In  many  new  systems,  new 
tasks  may  exist  reflecting  new  technologies  or  tasks  from  other 
systems  may  be  sufficiently  different  that  the  analogy  is 
inappropriate.  The  analyst  will  simply  have  to  use  judgment  to 
make  this  determination. 

When  this  occurs,  the  analyst  will  be  given  two  options  for 
estimating  performance  parameters,  1)  collecting  subject  matter 
expert  opinions  or  2)  constructing  estimates  based  on  further 
task  decomposition.  The  tradeoff  is  obvious  —  time  vs.  accuracy 
of  the  estimate.  The  analyst  will  be  provided  with  guidance  to 
help  make  that  decision2.  The  guidance  will  include  the 
following  considerations: 

1.  How  much  time  (subject  matter  expert  plus  analyst)  will 
be  required  to  further  decompose  the  task?  Specific 
considerations  will  be  given  to  complex  vs.  simple  tasks 
will  be  included  in  the  form  of  a  "time  required  to 
estimate"  algorithm. 

2.  How  much  more  accurate  is  the  estimate  likely  to  be  if 
decomposed  vs.  simply  estimated?  Specific 
considerations  will  be  given  to  the  availability  of 
qualified  subject  matter  experts  to  assist  in  the 
breakdown,  the  "fluidity"  of  the  system  design  as  it 
relates  to  the  task  (i.e.,  how  much  the  task  is  likely 
to  change  during  the  system  design  process) ,  and  the 
predictive  power  of  the  estimation  technique  (HOS  or 
motion-time  analysis) . 


20f  course,  the  analyst  will  be  able  to  avoid  this  analysis 
and  say  "I  (don't)  want  to  decompose  the  task." 
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The  analyst  will  be  asked  a  series  of  questions  relating  to 
the  above  items.  At  the  completion  of  this  analysis,  the  WAA 
will  give  him  or  her  its  recommendation  as  to  how  much  time  it  is 
likely  to  require  to  obtain  this  estimate  and  whether  it  will 
result  in  a  "much  better,"  "slightly  better,"  or  "probably  no 
better  or  worse"  estimate  of  performance.  These  suggestions  will 
be  made  through  applying  some  very  simple  heuristics  to  the 
analyst's  input. 

Should  the  analyst  choose  to  decompose  the  task  and  estimate 
performance  parameters,  the  software  will  lead  him  or  her  through 
the  process  of  decomposing  the  task  into  task  elements.  Then,  it 
will  pull  the  times  associated  with  each  of  the  task  elements 
from  the  appropriate  algorithm.  Again,  if  the  task  is  largely  a 
motor  task,  the  task  elements  will  be  drawn  from  a  motion-time 
study  data  base.  Motion-time  study  techniques  have  been  used  for 
decades  by  Industrial  Engineers  and  are  readily  available  and 
fairly  accurate.  If  the  tasks  require  a  substantial  amount  of 
information  processing,  then  HOS  time  estimation  algorithms  will 
be  employed. 

Output 

The  output  of  this  step  will  be  task  parameter  performance 
estimates  for  all  of  the  tasks  in  the  Task  Data  File.  These  will 
be  included  in  the  Task  Data  File. 

Sample  User  Interfaces 

Figures  21  through  24  present  sample  user  interfaces  for  the 
following  analyst  activities,  respectively: 

•  Selection  of  the  appropriate  portion  of  the  Task  Library 
to  review 

•  Windows  comparing  task  performance  parameters  in  the 
Task  Library  to  those  assigned  in  the  Task  Data  File  for 
a  particular  task 

•  Decision  analysis  to  determine  whether  to  use  subject 
matter  experts  or  task  decomposition 

•  The  development  of  task  performance  parameters  using 
motion  time  analysis  techniques 
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Sample  User  Interface  for  the  Selection  of 
the  Portion  of  the  Task  Library  to  Review 

Note:  Bold  Entry  indicates  Analyst  Input 


The  name  of  the  task  for  which  we  are  currently  looking  for  a 
similar  task  in  the  library  is  described  as  follows: 

(1)  Task  title:  Ammo  selection 

(2)  Mission  area:  Armor 

(3)  System  type:  Ml  Tank 

(4)  Task  description:  Depending  upon  the  target  type, 

distance,  and  environmental 
conditions,  the  type  of  ammo  to  be 
fired  at  the  target  must  be 
selected. 

Do  you  want  to  restrict  the  search  to  tasks  in  the  Mission  Area 
ARMOR  (type  yes  or  no)?  Y 

There  are  400  tasks  in  this  Mission  Area  and  they  belong  to  the 
following  types  of  systems: 

a.  M60  Tank 

b.  M60A  Tank 

Do  you  want  to  restrict  search  to  any  of  the  above  systems?  N 

Enter  any  key  words  that  must  be  in  the  task  title  for  tasks  to 
be  displayed  (or  hit  return  to  review  all  400  tasks)  -  AMMO 
AMMUNITION 

Below  are  all  tasks  from  the  Task  Library  in  Mission  Area  ARMOR 
with  the  words  AMMO  or  AMMUNITION  in  them  - 

a .  Check  AMMO 

b.  Load  Ammunition 

•  • 

•  • 

f.  Select  Ammunition 

Enter  the  letter  number  for  any  task  that  you  would  like  to 
review?  F 


Figure  21.  Review  Portion  of  Task  Library. 
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Sample  User  Interface  for  the  Comparison  of 
ask  Library  Data  to  the  Assigned  Task  Performance  Data 

Bold  Entry  indicates  Analyst  Input 


me  of  the  task  for  which  we  are  currently  WORKING  ON  is 
bed  as  follows: 

'ask  title:  Ammo  selection 

[ission  area:  Armor 

.ystern  type:  Ml  Tank 

’ask  description:  Depending  upon  the  target  type, 

distance,  and  environmental 
conditions,  the  type  of  ammo  to  be 
fired  at  the  target  must  be 
selected. 

TED  TASK  PERFORMANCE  PARAMETERS 

lean  Performance  Time  -  1.5  seconds 

Standard  deviation  -  Default  (one-third  of  the  mean) 

Probability  of  making  an  error  -  unassigned 

the  number  of  the  field  you  want  to  change  or  'return'  to 
ate  that  you  have  completed  work  on  this  task  -  3 


ame  of  the  task  FROM  THE  LIBRARY  is  as  follows: 

rask  title:  Ammunition  selection 

mission  area:  Armor 

System  type:  M60A  Tank 

rask  description:  Depending  upon  the  speed  of  tank 

movement,  the  target  type, 
distance,  and  environmental 
conditions,  the  type  of  ammo  to  be 
fired  at  the  target  must  be 
selected. 

PY  TASK  PERFORMANCE  PARAMETERS 

lean  Performance  Time  -  1.8  seconds 
Standard  deviation  -  0.6  seconds 
Probability  of  making  an  error  -  .02 


•  22.  Comparison  of  Task  Library  Data  to  Task  Performance 
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Sample  User  Interface  for  Aiding  the  Analyst 
In  Deciding  How  to  Assign  Task  Performance  Parameters 

The  task  that  we  are  considering  is  as  follows:  " 

Task  title:  Ammo  selection 

Mission  area:  Armor 

System  type:  Ml  Tank 

Task  description:  Depending  upon  the  target  type, 

distance,  and  environmental 
conditions,  the  type  of  ammo  to  be 
fired  at  the  target  must  be 
selected. 

Answer  the  following  questions  for  this  task: 

(1)  Are  the  system  components  associated  with  this  task  designed 
in  detail  (e.g.,  software  elements  and  hardware  designs  have 
been  defined) ?  Type  yes  or  no  -  NO 

(2)  Do  more  than  25%  these  system  components  already  exist 
(e.g.,  are  they  "off-the-shelf"  items)?  If  you  are  unsure, 
take  a  guess? 

(a)  less  than  25%  off  the  shelf 

(b)  more  than  25%  off  the  shelf 

type  a  or  b  -  A 

(3)  Are  the  task  elements  that  the  operator  will  be  asked  to 
perform  as  part  of  this  task  likely  to  change 

(a)  not  at  all 

(b)  some 

(c)  extensively 

type  a,  b,  or  c  -  C 

(4)  Do  you  have  the  subject  matter  expertise  available  to  help 
you  decompose  this  task  into  a  series  of  subtasks?  YES 

(5)  Roughly,  how  many  minutes  would  it  take  to  decompose  this 
task  into  5  to  20  subtasks  (whatever  would  be  appropriate) 

60 

Enter  the  number  of  the  question  to  which  you  would  like  to 
change  your  answer  or  'return*  for  an  analysis  -  ’return’ 

We  recommend  against  decomposing  this  task  and  suggest  that  you 
either  ask  a  subject  matter  expert  or  simply  make  a  guess. 


Figure  23.  How  to  Assign  Task  Performance  Parameters. 
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Sample  User  Interface  for  Aiding  the  Analyst  In  Conducting 
Motion  Time  Study  to  Assign  Task  Performance  Parameters 

Note:  Bold  Entry  indicates  Analyst  Input 

The  task  that  we  are  considering  is  as  follows: 

Task  title:  Load  heat  seeking  missile 

Mission  area:  Armor 

System  type:  Ml  Tank 

Since  you  are  using  motion-time-study  analysis,  you  must  decompose 
this  task  into  a  series  of  discrete  task  elements  that  are  at  the 
level  of  body  movements. 

You  must  also  have  rough  estimates  of  the  distances  and  required 
accuracies  of  these  movements. 

Below  are  the  subtasks  that  the  operator  will  perform  as  part  of 
this  task  that  have  already  been  defined: 

NOTE:  All  measurements  in  inches 

Body  Movement  Movement 

Task  Element  Name  Type  Distance  Accuracy 


1.  Turn  to  weapons 

2 .  Pick  up  missile 
3  .  Turn  to  turret 


Rotate  torso 
Lift  arm 
Rotate  torso 


25 

8 

15 


4 

5 
2 


8 .  Close  chamber 


Move  arm 


6 


2 


If  you  want  to  ADD,  MODIFY,  or  DELETE,  subtasks,  enter  A,  M,  or  D. 
If  you  want  to  Review  definitions  of  Body  Movement  Types,  enter  R. 
If  you  are  Finished  with  this  task  definition,  enter  F. 


Enter  A,  M,  D,  R,  orF-F 


Figure  24.  Motion  Time  Study  of  Task  Performance  Parameters. 
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3.2.6 _ Step  6  -  Assign  workload  values  to  each  operator  task 

(one  value  for  each  workload  channel  (i.e..  visual, 
auditory,  cognitive,  and  psvchomotor  workload!) 


Input 


External  Input  -  The  equipment  descriptions  presented  in  the 
contractor's  design  document,  particularly  the  description  of  the 
human  interfaces. 

Internal  Input  -  The  input  to  Step  6  will  be  the  task  listings 
(collected  in  Step  1)  and  the  Task  Data  File. 

Process 

The  purpose  of  Step  6  is  to  assign  workload  values  to  each 
task.  During  the  simulation  analysis  of  operator  workload  (which 
will  occur  in  subsequent  steps) ,  the  analyst  will  be  able  to  study 
the  demands  on  operators  when  they  must  perform  several  tasks 
simultaneously.  To  determine  these  collective  workload  demands,  we 
must  first  estimate  the  workload  demands  on  individual  tasks. 

The  technique  we  are  proposing  is  discussed  extensively  in 
Section  3.1.  It  was  developed  by  ARI  and  is  documented  in  its 
application  on  aviation  workload  assessment  by  McCracken  and 
Aldrich  (1984).  The  technique  was  modified  and  applied  through  the 
use  of  simulation  by  Micro  Analysis  and  Design  as  is  documented  in 
Laughery,  Drews,  Archer,  and  Kramme  (1986) .  Additionally,  the 
technique  is  being  used  by  the  ARI  Field  Unit  at  Fort  Rucker. 
Furthermore,  there  is  basic  research  which  supports  these  types  of 
techniques  for  evaluating  points  of  high  workload. 

Each  task  will  be  explored  with  respect  to  the  amount  of 
workload  it  requires  in  each  of  the  following  four  channels: 

1.  Visual  input  workload 

2.  Auditory  input  workload 

3.  Cognitive  information  processing  workload 

4.  Psychomotor  output  workload 

The  above  channels  are,  we  believe,  fairly  self-explanatory 
with  respect  to  the  type  of  workload  implied. 

The  analysts,  sitting  at  the  workstation,  will  step  through 
each  task  in  the  Task  Data  File  and  assign  workload  values  to  each 
of  the  above  four  channels.  They  will  do  this  by  examining  the 
task  description  accompanied  by  the  user  interface  description. 
Then,  they  will  review  four  benchmark  scales,  one  for  each  of  the 
four  channels,  and  select  the  number  which  most  closely  corresponds 
to  the  workload  in  the  operator  task  in  question. 
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As  an  example,  the  benchmark  scale  for  visual  attention  is 
presented  in  Table  3 . 

Table  3 

BENCHMARK  SCALE  FOR  VISUAL  WORKLOAD 

Task: 

Monitor,  scan,  survey 

Detect  movement,  change  in  size,  brightness 
Trace,  follow,  track 
Align,  aim,  orient 

Discriminate  symbols,  numbers,  words 
Discriminate  based  on  multiple  aspects 
Read,  decipher  text,  decode 

As  the  analyst  progresses  through  the  analysis,  he  will  be 
able  to  review  and  correct  previous  assignments  of  task  values. 

Outputs 

The  output  of  Step  6  will  be  the  addition  of  the  individual 
task  workload  data  to  the  Task  Data  File. 

Sample  User  Interfaces 

Figure  25  presents  a  sample  user  interface  for  the  assignment 
of  workload  values  for  one  task.  Note  that  when  the  analyst  is 
assigning  one  type  of  workload,  the  appropriate  benchmark  workload 
scale  is  provided  on  the  bottom  half  of  the  screen. 


Value: 

1 

2 

3 

4 

5 

6 
7 


3.2.7 _ Step  7  -  For  each  scenario  to  be  studied  within  each 

mission,  develop  descriptions  of  any  additional 
environmental,  threat,  or  other  system  conditions  which 
are  to  be  included  in  the  analysis 

In  some  cases,  analysts  may  choose  to  use  the  power  and 
flexibility  of  the  simulation  tool  underlying  the  WAA  to  analyze 
truly  closed-loop  human  operator  behavior.  For  example,  to  avoid 
complexity,  we  will  model  the  consequences  of  many  human  decisions 
as  probabilistic  events  rather  than  the  more  complex,  rule-based 
types  of  responses  that  really  occur.  In  evaluating  operator 
workload,  the  effect  of  this  will  be  minimal.  However,  some 
analysts  may  choose  to  study  these  consequences  more  rigorously. 
For  these  individuals,  we  will  provide  them  with  this  opportunity 
through  the  inclusion  of  the  full  power  of  a  simulation  modeling 
system. 
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Sample  User  Interface  for  Aiding  the  Analyst  In 
Assigning  Workload  Task  Performance  Parameters 


Note:  Bold  Entry  indicates  Analyst  Input 


The  task  that  we  are  considering  is  as  follows: 

Task  title:  Load  heat  seeking  missile 

Mission  area:  Armor 
System  type:  Ml  Tank 


The  workload  channels  that  you  must  define  are  as  follows: 


Workload  Channel 


Current  value 


(v)  Visual 
(a)  Auditory 
(c)  Cognitive 
(p)  Psychomotor 


2 

0 

undefined 


5 


You  are  currently  working  on  defining  VISUAL  workload 


Enter  v,  a,  c.  or  p  to  select  the  workload  channel  that  you  would 
like  to  change  or 

Enter  a  number  from  the  workload  scale  below  to  reassign  the  VISUAL 
workload  channel  value  or 

Enter  ' return '  to  complete  work  on  this  task. 


Enter  v,  a,  c,  p,  a  number,  or  'return'  -  C 


Figure  25.  Assigning  Workload  Task  Performance  Parameters. 
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Through  manipulation  of  this  system,  the  analyst  will  be  able 
to  include  detailed  models  of  the  hardware  and  software  system,  the 
threat  environment,  or  other  aspects  of  the  environment  as  desired. 
However,  for  the  analyst  not  wishing  this  complexity  nor  needing  to 
represent  the  finer  aspects  of  closed-loop  human  behavior,  this 
step  may  be  skipped. 

Input 


External  input  -  none 

Internal  input  -  The  completed  Task  Data  File  which  will  have 
resulted  from  performing  all  of  the  previous  steps. 

Process 


The  basic  process  of  this  step  will  be  for  the  analyst  to  call 
up  the  Micro  SAINT  Model  Development  portion  of  the  software.  This 
system  is  a  general  purpose  modeling  system  which  will,  in  essence, 
permit  the  modeler  to  construct  models  of  virtually  any  size  and 
complexity  within  the  constraints  of  the  Micro  SAINT  modeling 
system. 

The  analyst  will  have  the  option  of  two  types  of  "hooks"  to 
the  operator  workload  model.  The  first  type  of  hook  will  define 
how  the  performance  of  operator  tasks  affects  these  Micro  SAINT 
user  created  sub-models.  For  example,  the  completion  of  an 
operator  task  may  be  a  signal  to  commence  execution  of  a  sub-model 
associated  with  the  hardware  that  the  operator  "actuated"  in  the 
task. 


The  second  type  of  hook  that  can  be  defined  by  the  analyst 
would  be  how  the  completion  of  these  sub-model  tasks  affect  the 
execution  of  the  operator  tasks.  The  only  relationships  which  will 
be  permitted  are  as  follows: 

1.  An  operator  task  could  be  delayed  until  the  completion  of 
a  sub-model  activity  (e.g.,  the  representation  of  the 
completion  of  software  processing  of  threat  priorities 
before  the  operator  begins  determining  if  this 
prioritization  was  appropriate) . 

2.  The  task  sequencing  logic  could  be  affected. 

These  restrictions  to  hooking  sub-models  to  tasks  are,  we 
believe,  necessary  to  avoid  the  danger  of  the  analyst  constructing 
unwieldy  and  inaccurate  sub-system  models.  By  providing  more 
modeling  power,  we  could  be  providing  a  tool  which,  if  not  fully 
understood,  could  easily  result  in  incorrect  task  sequencing. 

Again,  we  believe  that  this  is  a  reasonable  balance  for  a  tool 
which  is  designed  for  addressing  operator  workload,  yet  should  be 
as  powerful  and  flexible  as  possible. 


El-92 


Output 

The  output  of  this  step  will  be  a  series  of  Micro  SAINT 
simulation  models  with  specific  hooks  to  the  operator  tasks 
defined. 

Sample  User  Interfaces 

Figure  26  presents  a  sample  user  interface  for  the  creation  of 
a  "hook"  to  a  Micro  SAINT  model  that  will  be  embedded  within  an 
operator  workload  model.  All  Micro  SAINT  user  interfaces  can  be 
reviewed  by  examining  the  Micro  SAINT  User's  Guide  (Archer,  Drews, 
and  Dahl,  1986). 


3.2.8 _ Step  8  -  Exercise  the  Computer  Simulation 

From  the  above  seven  steps,  we  will  have  developed  all  of  the 
data  required  to  conduct  a  computer  simulation  of  the  operator 
performing  his  tasks  for  the  purpose  of  evaluating  points  of  high 
operator  workload.  This  simulation  will  be  exercised  for  each 
mission  and  each  scenario  within  a  mission.  Therefore,  the  analyst 
may  conduct  a  number  of  simulations  based  on  the  required  number  of 
scenarios  identified  in  Step  4. 

Input 


External  Input  -  none 

Internal  Input  -  The  Task  Data  file  with  all  of  the 
information  created  in  Steps  1,  2,  3,  5,  and  6,  the  Scenario  Data 
File  created  in  Step  4,  and  the  Micro  SAINT  sub-models  created  in 
Step  7 . 

Process 


The  process  will  be  very  simple.  Since  the  simulation  will  be 
a  Monte-Carlo  Simulation,  the  analyst  will  only  need  to  specify  the 
number  of  times  that  he  or  she  would  like  to  run  the  scenario  for 
data  collection,  the  frequency  of  storing  operator  workload  data 
(e.g.,  every  second),  and  on  what  disk  file  to  store  the  data.  The 
software  will  link  all  tasks,  conduct  the  simulation,  and  collect 
the  data  without  further  operator  input,  just  as  it  does  with  Micro 
SAINT.  The  analyst  will,  simply,  tell  the  system  to  "GO"  and  come 
back  several  minutes  later. 

If  the  analyst  chooses,  he  or  she  will  be  able  to  watch  tne 
simulation  "run."  As  with  Micro  SAINT,  several  execution  modes 
will  be  available,  from  a  "let  me  know  when  you're  done"  mode  to  a 
"show  me  every  task  the  operator  performs"  mode.  The  latter  will 
be  a  useful  mode  for  ensuring  that  the  scenario  runs  as  planned. 
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Sample  User  Interface  for  Aiding  the  Analyst  In 
Hooking  Micro  SAINT  Models  to  the  Operator  Workload  Model 

Note:  Bold  Entry  indicates  Analyst  Input 


(1)  The  name  of  the  Micro  SAINT  model  that  you  want  to  hook  is 

IDTHREAT 

(2)  A  short  description  of  this  model  is  as  follows: 

This  model  represents  the  processes  of  threat 
identification  by  the  threat  processing  computer. 

(3)  The  nature  of  this  hook  is  a  hold  task  until  this  model  is 
complete 

(4)  The  operator  task  that  will  be  held  until  this  model  is 
complete  is  ’Verify  correct  identification.’ 


Enter  the  field  number  to  change  the  hook  or  type  R  to  review  the 
model  listed  in  field  1  above  - 


Figure  26.  Hooking  Micro  SAINT  Models  to  the  Operator  Workload 
Model. 
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Output 


The  output  of  Step  8  will  be  a  series  of  data  files 
describing,  for  each  run,  the  collective  workload  values  across  all 
operator  tasks  at  each  measurement  interval  as  well  as  the  operator 
tasks  which  contributed  to  that  workload.  These  data  will  permit 
all  analyses,  which  will  be  discussed  in  Steps  9  and  10,  to  be 
conducted . 

Samples  of  User  Interfaces 

Figure  27  presents  a  sample  user  interface  which  will  be 
presented  to  the  analyst  in  setting  up  a  simulation  run. 


3.2.9 _ Step  9  -  Review  the  output  of  the  computer  simulation 

Input 


External  input  -  Subject  matter  expertise  is  desired  but  not 
necessary  to  conduct  the  data  analyses. 

Internal  input  -  The  data  files  created  during  the  simulation 
in  Step  8. 

Process 


Step  9  will  be  the  point  at  which  the  analyst  has  to  "make 
sen^e"  of  the  data.  In  this  step,  the  analyst  must  define  high 
workload  and  discover  points  at  which  this  overload  seems  likely  to 
take  place. 

The  process  will  involve  two  distinct  substeps,  1)  defining 
operator  overload  and  2)  reviewing  the  data.  Let  us  discuss  these 
steps  individually. 

Defining  operator  overload  -  Using  the  proposed  methodology, 
the  analysts  can  define  points  of  operator  overload  in  many  ways. 
They  will  have  two  basic  questions  to  address  -  1)  what  are  the 
relationships  among  the  workload  variables  for  each  workload 
channel  (visual,  auditory,  cognitive,  and  psychomotor)  and  2)  what 
is  the  acceptable  workload  "window"  at  different  points  in  the 
scenario.  For  both  defining  overload  relationships  and  window 
size,  the  system  will  include  several  default  definitions.  This 
will  permit  the  analyst  who  does  not  want  or  feel  qualified  to  make 
these  judgments  to  use  reasonable  values.  These  values  will  be  set 
based  on  research  findings  from  ongoing  research  at  Ft.  Rucker  and 
being  planned  by  the  Canadian  Ministry  of  Defense. 


El-95 


Sample  User  Interface  for  Aiding  the  Analyst  In 
Setting  Up  a  Simulation  Run  of  the  Operator  Workload  Model 

Note:  Bold  Entry  indicates  Analyst  Input 

(1)  The  operator  workload  model  that  you  will  be  running  is 

titled  Ml  Tank  -  one  on  one,  stationary 

(2)  This  model  will  be  run  for  10  trials 

(3)  The  data  will  be  stored  on  the  file  Ml  RUNOi 

(4)  Data  will  be  collected  every  simulated  .5  seconds 

Enter  the  field  number  to  change  the  above  information  or  enter 
'GO'  to  start  the  simulation  -  GO 


Figure  27.  Setting  Up  a  Simulation  Run. 
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During  the  simulation,  the  workload  demands  across  all  tasks 
being  performed  simultaneously  will  be  summed  within  each  channel 
(e.g.,  two  tasks  requiring  3  and  2  units  of  visual  workload  will 
result  in  a  cumulative  demand  of  3+2=5  units  of  visual  workload) . 
However,  the  simulation  will  not  inherently  define  the  values  of 
these  workload  values  which  represent  "too  much  workload."  The 
analyst  will  be  given  the  option  of  using  boolean  relationships  to 
define  these  points.  For  example,  the  analyst  could  define 
overload  as  "points  in  which  any  of  the  workload  channels  exceed  a 
value  of  8."  Alternately,  the  analyst  could  append  to  that 
definition  the  following  "...  or  all  of  the  workload  channels 
summed  exceeds  16."  In  practice,  the  analyst  may  wish  to  review 
the  data  using  several  different  definitions  of  "operator  overload" 
to  evaluate  the  sensitivity  of  his  predictions  about  overload  to 
the  definition  used. 

Second,  it  is  reasonable  to  study  workload  looking  at  a  window 
during  which  the  operator  could  "spread  out"  his  workload.  For 
example,  even  though  two  tasks  are  being  performed  simultaneously 
at  a  given  instant  in  the  simulation,  practically,  the  analyst  may 
spread  them  out  over  a  period  of  several  seconds,  assuming  that  in 
that  several  second  "window"  there  was  a  point  of  reduced  operator 
workload.  The  analyst  may  define  the  length  of  that  window  in  time 
units.  To  further  complicate  matters,  the  length  of  the  window  may 
be  different  at  different  points  in  the  mission.  At  points  where 
immediate  operator  response  is  required  (e.g.,  dealing  with  an 
incoming  threat),  there  may  be  no  window.  At  other  points,  the 
window  may  be  very  wide.  The  analyst  will  have  the  option  of 
defining  both  window  sizes  and  mission  periods  that  the  window  size 
is  in  effect.  "Mission  periods"  will  be  defined  by  either  mission 
times  (e.g.,  "at  time  0  through  300  seconds,  the  window  is  three 
seconds  wide,  thereafter  it's  one  second  wide")  or  tasks  which 
drive  window  length  (e.g.,  "window  size  is  three  seconds  except 
when  the  operator  is  engaging  in  threat  management,  then  it's  one 
second  wide.").  A  "mission  times"  definition  is  mission  specific 
and,  therefore,  every  simulated  mission  will  need  to  be  explored 
individually.  In  using  tasks  to  define  window  length,  the  analyst 
will  be  able  to  develop  general  definitions  which  are  applicable 
across  all  scenarios  and  missions. 

Again,  the  analyst  may  wish  to  study  several  definitions  to 
explore  the  effect  on  overload  predictions  to  his  definition  of 
workload  windows. 

Reviewing  the  Data  -  Once  the  analyst  creates  these 
relationships  and  windows  dnfining  operator  overload,  the  analyst 
will  need  to  identify  the  scenarios  to  analyze.  Then,  the  analyst 
will  be  given  the  option  of  reviewing  the  data  manually  or 
receiving  summary  reports. 
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Manual  review  of  the  data  will  involve  starting  the  analysis 
and  then,  every  time  a  point  of  operator  overload  is  encountered  in 
one  of  the  scenarios  being  reviewed,  the  following  information  will 
be  presented  to  the  analyst: 

1.  The  simulated  mission  time 

2.  The  operator  tasks  which  are  currently  active  and  their 
individual  workload  demands 

3.  The  cumulative  workload  demands 

4.  The  current  definition  of  operator  overload  being 
employed  (relationships  and  window  size) 

At  this  point,  the  analyst  may  declare  this  situation  as  truly 
representing  overload  or  not  representing  overload. 

If  the  analyst  only  desires  summary  findings  for  each 
scenario,  the  analysis  will  compute  all  points  at  which  overload 
occurred.  Then,  it  will  present  these  as  a  percentage  of  mission 
time  that  the  operator  was  overloaded.  Additionally,  the  analysis 
will  present  the  operator  with  the  opportunity  to  review  nine 
graphical  presentations  on  the  display  or  in  hard  copy.  These 
presentations  will  present  1)  operator  workload  in  each  of  the 
four  workload  channels,  2)  histograms  representing  the  frequency  of 
workload  levels  within  each  of  the  four  channels,  and  3)  the  points 
at  which  operator  overload  occurred  within  a  mission.  Examples  of 
each  of  these  nine  analyses  are  presented  in  Figures  28  through  36. 

Output 

The  output  of  Step  9  will  be  a  series  of  times  in  each  of  the 
scenarios  studied  where  operator  overload  is  expected  to  occur. 

This  will  be  in  the  form  of  hard  copy  printouts  describing  the 
information  discussed  in  the  previous  subsection. 

Sample  User  Interfaces 

Figure  37  presents  a  sample  user  interface  for  defining  the 
relationships  which  constitute  operator  overload.  Figure  38 
presents  a  sample  user  interface  for  defining  workload  window 
sizes.  Figure  39  presents  a  sample  user  interface  for  the  analyst 
during  manual  review  of  the  data  where  he  must  determine  whether 
this  point  represents  operator  overload. 
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Figure  32.  Histogram  of  Visual  Workload  Throughout  a  Mission. 
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Figure  33.  Histogram  of  Auditory  Workload  Throughout  a  Mission. 
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ATTENTION  ANALYSIS 
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Figure  34.  Histogram  of  Cognitive  Workload  Throughout  a  Mission. 
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Figure  35.  Histogram  of  Psychomotor  Workload  Throughout  a  Mission. 
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Sample  Description  of  Points  at  Which  Overload  Occurred 


SUMMARY  WORKLOAD  ANALYSIS  FOR  JOB  "TANK  COMMANDER" 

Note:  The  following  definition  of  operator  overload  was  used  in 

this  analysis: 

V+A+C+P  GREATER  THAN  15  OR  (V  GREATER  THAN  10  OR  A 
GREATER  THAN  10  OR  C  GREATER  THAN  10  OR  P  GREATER 
THAN  10) 

and  the  following  tasks  were  not  considered  in  computing 
workload  values  (i.e.,  they  were  treated  as  though  they 
were  performed  by  another  operator) " 

NONE  -  ALL  TASKS  INCLUDED 

Summary : 

Operator  was  in  an  overload  situation  12%  of  the  time. 

The  following  tasks  were  being  performed  in  over  50%  of  these 
overload  situations: 

NONE 

The  following  tasks  were  being  performed  in  between  25%  and 
50%  of  these  overload  situations: 

VISUALLY  MONITOR  OUTSIDE  THE  TANK 

The  following  tasks  were  being  performed  in  less  than  25%  of 
these  overload  situations: 

MONITOR  ROTATION  OF  TURRET 
ISSUE  "FIRE"  COMMAND 


Would  you  like  to  reconduct  the  workload  analysis  under  the 
assumption  that  some  of  the  tasks  were  reallocated?  Y 

What  task(s)  would  you  like  to  treat  as  reallocated?  (Note:  this 
analysis  should  be  considered  as  preliminary  -  a  proper 
reallocation  of  tasks  and  an  associated  analysis  must  be  performed 
before  finalizing  results: 

Visually  monitor  outside  the  tank 


Figure  36.  Points  of  Operator  Overload. 
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Sample  User  Interface  for  Defining  Operator  Overload 


Note:  Bold  Entry  indicates  Analyst  Input 


Note:  In  defining  operator  overload  you  may  use  the  following  four 

variables: 

V  (for  visual  attention) 

A  (for  auditory  attention) 

C  (for  cognitive  attention) 

P  (for  psychomotor  attention) 

and  you  can  use  the  following  logical  relationships 

GREATER  THAN 
LESS  THAN 
EQUAL  TO 
AND 
OR 

and  you  can  use  the  following  mathematical  relationships: 

+  (addition) 

-  (subtraction) 

*  (multiplication) 

/  (division) 

The  current  definition  of  overload  is  as  follows: 

(1)  V+A+C+P  GREATER  THAN  15  OR  (V  GREATER  THAN  10  OR  A  GREATER 
THAN  10  OR  C  GREATER  THAN  10  OR  P  GREATER  THAN  10) 


Enter  1  to  change  the  definition  of  operator  overload 
1 D'  to  use  default  definitions  of  overload 


Figure  37.  Defining  Operator  Overload. 


Sample  User  Interface  for  Defining  Operator  Workload  Window  Size 


The  Window  Size  is  currently  set  as  follows: 

(1)  2  seconds  during  the  scenario 

(2)  Except  when  the  following  tasks  are  executing: 

Task  title  Window  size 

1.  Change  position  6  seconds 

2.  Identify  incoming  threat  1  second 

(3)  And  except  during  the  following  scenario  times 

Time  Range  Window  size 

NONE  DEFINED 


Enter  1  to  change  the  default  window  size 

2  to  change  the  tasks  that  define  other  window  sizes 

3  to  change  time  intervals  that  define  other  window  sizes 
'  D'  to  use  the  default  definition  window  size 


Figure  38.  Defining  Operator  Workload  Window  Size. 


Sample  Interface  Presenting  a  Point  of  Operator  Overload 


Simulation  Run  Being  Reviewed  -  M60  RUN01 


At  simulated  time  402  seconds  by  this  definition  of  operator 
overload 

V+A+C+P  GREATER  THAN  15  OR  (V  GREATER  THAN  10  OR  A  GREATER 
THAN  10  OR  C  GREATER  THAN  10  OR  P  GREATER  THAN  10) 

Operator  overload  seems  to  have  occurred  in  the  operator  titled  LHX 
PILOT 


At  that  time,  the  following  tasks  were  being  performed  by  the  Tank 
Commander: 

Workload  Values 

Tasks  Visual  Auditory  Cognitive  Psychomotor 


Check  altimeter  403  0 

Identify  incoming  526  0 

threat 


Should  this  be  stored  as  a  situation  of  operator  overload? 
(type  yes  or  no)  -  NO 


Figure  39.  A  Point  of  Operator  Overload. 
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3.2.10  Step  10  -  Determine  acceptability  of  operator  staffing 
plan  and,  if  discrepancies  exist,  define  the  points  at 
which  solutions  to  operator  overload  must  be  found 

Input 

External  -  Subject  matter  expertise  may  be  required  to  make 
some  of  the  critical  decisions  regarding  overall  acceptability. 

Internal  -  The  data  generated  in  Step  9 . 

Process 

The  WAA  will  provide  the  analyst  with  a  set  of  guidelines  to 
help  him  make  the  decision  as  to  the  acceptability  of  the  system 
design.  Virtually  every  system  in  which  a  human  is  involved  is 
going  to  be  one  in  which  the  potential  for  human  task  overload 
exists.  One  can  always  complicate  the  scenario  to  the  point  at 
which  the  human  has  more  work  than  he  can  effectively  handle.  The 
key  questions  about  the  effect  of  this  on  the  system  design's 
acceptability  are  the  following: 

1.  Are  these  points  of  overload  so  common  that  no  operator 
can  be  expected  to  reasonably  perform  all  or  most  of  his 
required  activities  throughout  many  segments  of  the 
mission? 

2.  Are  points  of  extreme  overload  found  such  that,  at  these 
points,  the  operator  is  likely  to  become  immediately 
overwhelmed? 

3.  Do  points  of  significant  overload  occur  at  points  where 
mission  success  or  survivability  are  in  danger? 

The  first  question  will  be  addressed  by  examining  the  summary 
data  from  the  scenarios.  If  operator  overload  is  occurring  in 
excess  of  10%  of  the  mission  and  average  workload  throughout  a 
mission  is  high,  then  the  analyst  will  be  advised  to  suggest 
restaffing  or  redesign  of  the  system. 

The  second  and  third  questions  will  be  addressed  by  reviewing 
the  points  at  which  overload  occurred.  A  subject  matter  expert 
will  probably  be  very  helpful  in  making  the  appropriate 
determinations  as  to  whether  the  workload  is  extremely  high  or 
whether  the  mission  itself  is  endangered  at  that  point.  If  points 
in  the  mission  are  identified  that  are  clear  problems,  these  will 
be  automatically  stored  in  a  reports  data  file. 
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The  outputs  of  this  step  will  be  a  series  of  scenario 
descriptions  and  points  in  those  scenarios  where  operator  workload 
was  found  to  be  excessive.  Additionally,  a  set  of  summary 
statistics  on  each  mission  analyzed  will  be  presented  (e.g., 
percentage  of  time  in  overload  situation,  definition  of  overload, 
etc . )  . 


When  the  results  of  a  simulation  indicate  that  the  current 
staffing  plan  did  not  produce  unacceptable  operator  workload  levels 
and  the  system  performance  requirements  have  been  met,  the  analyst 
can  obtain  a  manpower  summary  report  that  contains  the  following 
data: 

•  The  operator  jobs 

•  The  tasks  that  were  assigned  to  each  job 

•  The  number  of  operators  that  were  required  for  each  job 
Sample  User  Interfaces 

Figure  40  illustrates  a  sample  interface  summarizing  the 
results  of  the  analysis. 


3.2.11  Step  11  -  Reallocate  tasks  to  jobs  or  add  operators  in  a 
wav  that  would  result  in  successful  system  operation  and 
acceptable  operator  workload 


Input 

External  Input  -  To  ensure  that  any  revisions  to  the 
allocation  of  tasks  to  jobs  is  reasonable,  we  will  advise  the 
analyst  that  a  subject  matter  expert  should  be  available.  However, 
the  absence  of  a  subject  matter  expert  does  not  make  this  analysis 
impossible. 

Also,  the  system  performance  requirements  identified  by  the 
SPREA  (Product  1)  will  be  required. 

Internal  Input  -  The  Task  Data  File,  the  Scenario  data  file, 
and  the  results  of  the  simulation  will  be  the  primary  input  to  this 
step. 
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Sample  User  Interface  Presenting  Summary  of  Workload  Findings 


Scenario  -  M60  RUN01 

Percentage  of  time  that  each  of  the  operators  was  in  an  overload 
situation: 

Tank  Commander  -  11% 

Gunner  -  6% 

Loader  -  0% 

Driver  -  0% 

Do  you  want  to  review  a  list  of  tasks  for  any  of  the  operators  that 
were  involved  in  overload  situations?  Yes 

Which  Operator?  Tank  Commander 


The  following  tasks  were  involved  in  overload  situations  for  the 
TANK  COMMANDER 


Task  name 


Percentage  of  time 
being  performed  that 


that  this  task  was 
overload  was  occurring 


Identify  target 

8% 

Lase  to  target 

60% 

Figure  40.  Summary  of  Workload  Analysis  Results. 
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Process 


The  process  of  determining  how  to  reallocate  tasks  to 
operators  will  involve  the  following  substeps: 

1.  Determine  whether  System  Performance  Requirements  as 
specified  in  Product  1  are  being  met. 

2.  Determine  (from  the  previous  step)  the  points  at 
which  high  workload  for  one  operator  coincides  with 
low  workload  for  another  operator. 

3.  Reallocate  tasks  among  operators  based  on  the 
information  from  substeps  1  and  2  above  with  due 
consideration  given  to  control  and  display 
accessability  constraints. 

4.  Evaluate  new  allocation  of  operator  tasks  using 
Steps  4  through  10  (as  described  in  Sections  3.2.1 
through  3.2.10). 

5.  Iterate  substeps  1  through  4  above  until  either  an 
acceptable  allocation  of  operator  tasks  to  jobs  is 
discovered  or  it  becomes  clear  that  at  least  one 
more  operator  is  required. 

6.  If  another  operator  is  required,  check  whether  the 
design  will  support  an  additional  operator 
(supportability  constraint) . 

7.  If  another  operator  can  be  added,  allocate  tasks  to 
the  new  operator. 

8 .  Iterate  substeps  1  through  4  above  until  either  an 
acceptable  allocation  of  operator  tasks  to  jobs  is 
discovered  or  it  becomes  clear  that  at  least  one 
more  operator  is  required. 

9.  Repeat  substeps  6,  7,  and  8  above  until  an 
acceptable  solution  is  found  or  it  is  infeasible  to 
add  more  operators,  thereby  rendering  the  design 
infeasible  within  the  currently  presented  personnel 
and  training  constraints. 

Most  of  the  above  steps  have  been  discussed  in  detail  in  other 
parts  of  this  paper.  However,  let  us  emphasize  some  of  the  salient 
points. 

It  is  in  substep  1  that  we  ensure  that  the  contractor's 
design,  in  essence,  meets  the  design  specifications  with  respect  to 
functions  performed  by  humans.  As  we  noted  earlier  in  this  paper, 
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we  are  not  relying  on  contractor  estimates  of  human  task 
performance  time  and  accuracy,  even  if  they  are  provided.  Rather, 
we  will  estimate  these  parameters  independently.  Therefore,  it  is 
entirely  possible  that  their  design  and  the  associated  logical 
allocation  of  tasks  could  result  in  low  operator  workload  but  not 
minimally  acceptable  functional  performance.  For  example,  a 
contractor's  task  analysis  may  indicate  that  tasks  are  performed  in 
series  by  an  operator  to  minimize  workload  associated  with 
performing  several  tasks  simultaneously.  Based  on  contractor  time 
estimates,  performing  tasks  serially  would  still  result  in 
acceptable  performance.  However,  in  applying  this  tool,  the 
analyst  may  determine  that  the  time  estimates  were  low  and, 
therefore,  the  human  took  longer  to  perform  the  function  than  the 
minimally  acceptable  criteria  (defined  in  Product  1)  permitted. 

This  being  the  case,  this  allocation  of  tasks  to  operators  is  not 
acceptable  unless  an  alternative  task  allocation  arrangement  can  be 
identified  (e.g.,  assign  some  of  the  tasks  to  other  operators  and 
test  to  ensure  that  workload  is  acceptable) . 

Therefore,  in  using  the  WAA  to  assign  tasks  to  jobs,  the 
analyst  must  consider  whether  or  not  the  assignments  still  result 
in  an  acceptable  level  of  human  performance  of  functions.  If  not, 
then  the  allocation  of  tasks  to  operators  must  be  reconsidered. 

To  determine  whether  human  performance  satisfies  the  minimally 
acceptable  performance  criteria,  the  analyst  will  need  to  review 
the  outputs  of  the  SPREA  (Product  1)  and  map  SPREA  tasks  to  human 
operator  tasks  or  groups  of  tasks.  This  will  involve  a  review  of 
the  Product  1  analysis  for  the  system  under  consideration.  Then, 
the  performance  criteria  defined  in  this  analysis  will  be  compared 
to  the  performance  estimates  obtained  from  the  simulation  run 
conducted  in  Step  8.  If  the  performance  criteria  are  met,  then 
this  does  not  need  to  be  a  consideration  in  the  reallocation  of 
tasks  among  operators. 

In  Substep  2,  the  analyst  will  be  given  information  to  assist 
him  in  reallocating  tasks.  He  will  be  able  to  review  the  workload 
simulation  results  to  determine,  for  points  of  high  operator 
overload,  whether  there  were  points  of  low  workload  for  another 
operator. 

In  Substep  3,  tasks  will  be  reallocated  to  operators  based  on 
the  nature  of  the  problems  with  the  current  task  allocation  scheme 
which  were  identified  in  Substeps  1  and  2.  The  WAA  will  not 
provide  the  analyst  with  any  specific  task  assignment  algorithms. 
This  is  a  difficult  job  which  will  consider  a  number  of 
interrelated  factors,  many  of  which  are  not  amenable  to  automation. 
The  analyst,  with  the  aid  of  the  analysis  tools  provided  in  the 
Workload  Diagnostics  Template,  will  have  to  make  some  guesses  as  to 
what  the  appropriate  reallocation  of  tasks  among  operators  might 
be. 
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As  the  analyst  is  considering  reallocating  tasks,  the  WAA  will 
remind  him  or  her  of  the  control  and  display  accessability 
constraints  that  must  be  considered.  This  will  aid  the  analyst  in 
ensuring  that  he  does  not  assign  tasks  to  operators  when  the 
controls  or  displays  needed  to  perform  that  task  are  not  within  his 
reach  or  view. 

Once  the  analyst  has  performed  the  first  three  substeps,  then 
he  will  have  developed  a  new  "hypothesis"  regarding  the  allocation 
of  tasks  to  operators  (jobs) .  Substep  4  will  be  to  test  this 
hypothesis  by  repeating  Steps  4  through  10  of  the  WAA  as  discussed 
in  the  previous  sections.  This  effort  will  be  far  less  time 
consuming  than  the  initial  analysis  since  most  of  the  tasks  will 
not  change  and,  even  of  those  which  are  reallocated,  many  will  not 
change . 

As  is  the  case  with  many  complex  systems,  the  simple 
"reallocation  of  tasks"  will  frequently  have  many  rippling  effects. 
Therefore,  the  analyst  can  expect  that  he  may  have  to  try  several 
alternatives  until  he  finds  one  that  is  acceptable.  This  is  the 
intent  of  Substep  5. 

On  the  other  hand,  it  may  be  obvious  very  quickly  that  there 
is  no  alternative  which  will  satisfy  both  the  workload  constraints 
and  the  system  performance  criteria.  Therefore,  to  satisfy  these 
constraints,  additional  operators  must  be  added.  In  Substep  6,  we 
will  ensure  that  adding  an  additional  operator  will  not  violate  the 
supportability  constraint.  In  other  words,  the  design  will  support 
an  additional  operator. 

When  an  operator  is  added,  then  we  must  reallocate  tasks 
(Substep  7)  and  rerun  the  first  four  substeps  of  this  step  to 
ensure  that  workload  and  system  performance  criteria  are  adequately 
addressed.  Again,  this  process  is  continued  until  it  becomes 
obvious  that  another  operator  must  be  added  (Substep  8) . 

At  some  point,  it  may  become  obvious  that  the  system  cannot 
support  the  number  of  operators  required  to  meet  the  system 
performance  criteria  without  creating  excessive  operator  workload. 
At  this  time,  the  work  of  the  WAA  is  completed.  This  in  not  to  say 
that  the  design  is  infeasible  with  respect  to  MANPRINT  issues. 
Rather,  it  becomes  a  question  of  whether  these  performance  and 
workload  criteria  could  be  met  by  using  a  more  select  operator 
population  or  by  providing  more  training.  These  questions  are  in 
the  domain  of  Product  6. 

On  the  other  hand,  at  some  point  an  acceptable  allocation  of 
tasks  to  operators  may  be  found.  This  is  not  to  say  that  this 
definition  of  jobs,  tasks  per  job,  and  numbers  per  job  necessarily 
represents  a  feasible  solution  from  a  manpower  perspective.  We 
have  not  considered  the  overall  manpower  constraint  (the  output  of 
Product  2)  in  this  analysis.  In  fact,  while  the  system  design  may 
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support  more  operators,  the  Army's  manpower  availability  may  not. 
However,  we  will  have  found  that,  given  adequate  manpower,  the 
system  can  be  used  successfully. 

Outputs 

At  the  completion  of  this  step,  regardless  of  the  outcome,  the 
analyst  will  call  out  the  Reports  Generation  Template.  This 
software  will  then  print  out  a  summary  of  job  titles,  numbers  of 
each  job  per  system,  and  tasks  per  job.  The  analyst  will  be 
presented  with  the  opportunity  for  generating  more  detailed  reports 
describing  task  performance  parameters,  percentage  utilization  of 
each  task,  and  a  host  of  other  potentially  interesting  findings. 

User  Interfaces 


The  user  interfaces  for  these  tasks  will  be  the  same  user 
interfaces  which  were  presented  for  the  creation  of  Task  and 
Scenario  Data  Files  accordingly. 


3.2.12  Summary  of  the  WAA  Process 

The  WAA  will  begin  with  a  description  of  the  operator (s) 
activities  provided  by  the  contractor,  from  predecessor  or 
comparable  existing  systems,  or  by  the  output  of  Product  1.  Task 
performance  parameters  (speed  and  accuracy)  will  be  estimated  using 
a  variety  of  potential  methods  depending  upon  the  time  available  to 
conduct  this  analysis  and  other  factors.  Additionally,  workload 
estimates  for  tasks  will  be  derived  based  on  task  and  operator 
interface  descriptions. 

The  missions  and  scenarios  selected  for  study  will  be  those 
anticipated  to  require  high  operator  workload.  The  scenarios  will 
be  described  in  a  manner  that  will  permit  their  incorporation  into 
computer  models.  No  computer  programming  will  be  required. 

Once  the  operator  tasks  and  scenario  are  defined,  a  computer 
model  will  be  run.  No  computer  expertise  on  the  part  of  the 
analyst  will  be  required  to  create  or  run  this  simulation. 

The  analyst  will  review  data  from  the  simulation  to  determine 
points  of  operator  overload  as  he  or  she  chooses  to  define  it.  If 
points  of  operator  overload  occur  too  frequently,  then  the  analyst, 
if  he  chooses  to,  will  be  able  to  reallocate  tasks  across  operators 
or  add  operators  and  then  rerun  the  simulation  to  determine  if 
operator  workload  is  acceptable.  As  he  or  she  does  this,  the 
analyst  will  ensure  that  task  reallocations  do  not  violate  the 
control  and  display  accessibility  constraint  and  that  the  addition 
of  operators  does  not  violate  the  supportability  constraint. 


El-117 


The  analyst  will  continue  to  use  this  hypothesis  testing 
approach  to  determine  a  configuration  of  operator  jobs,  tasks  per 
job,  and  numbers  of  people  per  job  that  will  meet  system 
performance  requirements,  not  violate  manpower  constraints,  and 
not  cause  any  of  the  operators  to  experience  excessive  overload. 


3.3  WAA  SOFTWARE  ELEMENTS 

In  this  section  we  will  present  preliminary  software  designs 
and  data  sources  for  the  software  elements  which  were  defined  in 
Section  3.1.4.  These  elements  were  grouped  into  the  following  four 
categories: 

1.  The  Templates  for  users  to  create  Files  and  analyze 
results  of  the  analyses 

2.  The  Libraries  including  historical  information  which  the 
analyst  can  use  to  construct  his  analysis 

3 .  The  Files  which  the  user  creates  representing  the 
operator's  performance  within  a  mission 

4.  The  Models  to  run  the  operator  workload  simulation  and 
generate  data  for  analysis 

Over  all  of  the  software  elements  will  be  an  Applications 
Manager  which  will  be,  essentially,  the  operating  system  in  which 
the  analyst  works.  Within  the  Applications  Manager  will  be  a 
Report  Generator.  The  Report  Generator  will  allow  the  preparation 
of  reports  which  detail  the  operator  tasks,  task  sequencing, 
scenario  information,  results  of  a  simulation  run,  and  any  other 
pertinent  information  associated  with  each  scenario  that  the 
analyst  has  created. 

Let  us  now  discuss  in  some  detail  each  of  these  software 
elements  in  some  detail.  Each  discussion  will  be  subdivided  first 
into  the  specific  software  elements  that  were  identified  in  Section 
3.1.3.  Then,  for  each  of  these,  we  will  discuss  the  basic  software 
architecture  and  the  sources  of  data  (where  appropriate) .  For 
software  elements  which  are  programs  (the  Templates  and  Models) ,  we 
will  present  high-level  flow  charts.  For  software  elements  which 
are  data  (the  Libraries  and  Data  Files) ,  we  will  define  the 
information  which  will  be  stored  in  the  data  base  and  the  sources 
of  these  data  (in  the  case  of  the  libraries) . 

3.3.1  The  Templates 

Function  and  task  definition  template 

This  program  will  lead  the  analyst  through  the  creation  of 
lists  of  operator  functions  and  tasks  for  the  system  being  studied. 
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It  will  include  definition  of  task  performance  parameters,  workload 
requirements,  and  limitations  on  task  performance  (e.g.,  the 
availability  of  resources,  the  completion  of  other  tasks) .  In 
fact,  it  will  lead  the  analyst  through  the  performance  of  Steps  2, 
3,  4,  and  5  as  of  the  operator  workload  analysis  process  as  defined 
in  Sections  3.2.2,  3.2.3,  3.2.4,  and  3.2.5. 

Figure  41  presents  a  high  level  flow  chart  for  the  Function 
and  task  definition  template.  Figure  42  presents  a  more  detailed 
breakdown  of  the  portion  of  the  template  focused  on  defining  crew 
positions  and  tasks  that  each  crew  member  performs.  Figure  43 
presents  a  flowchart  for  the  task  workload  parameter  input.  In  the 
next  Section,  we  will  discuss  the  portion  of  this  template 
associated  with  task  performance  parameter  estimation. 

Please  note  that  all  user  inputs  associated  with  sample 
interfaces  which  were  presented  in  Section  3.2  are  duly  indicated. 

The  task  performance  parameter  estimation  template 

This  program  will  lead  the  analyst  through  the  estimation  of 
task  performance  parameters  including  task  performance  time, 
standard  deviation  of  performance,  and  the  probability  of  making  an 
error.  This  software  element  will  be  embedded  in  the  function  and 
task  definition  template  discussed  above,  but  it  is  of  sufficient 
importance  and  complexity  to  distinguish  for  the  purposes  of 
discussion  in  this  paper. 

We  are  using  the  following  three  approaches  to  assisting  the 
analyst  in  defining  task  performance  p'-ameters: 

1.  An  analysis  of  comparable  systems  which  are  currently 
fielded  in  the  Army  and  for  which  operator  performance 
data  reside  in  the  Task  Library 

2.  Subject  matter  expert  estimates  based  on  the  new  system's 
description  and  a  background  with  similar  fielded  systems 

3.  Task  decomposition  and  analysis  whereby  the  analyst  must 
decompose  the  overall  operator  task  into  task  elements 
and  synthesize  overall  task  time  by  estimating  the  task 
element  times 

Figure  44  presents  a  flowchart  of  the  overall  process  of  this 
template.  Figures  45,  46,  and  47  present  flowcharts  for  the 
estimation  of  task  performance  parameters  by  the  above  three 
methods . 
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Figure  41.  High  Level  Flowchart  for  the  Function  and  Task 
Definition  Template 
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Figure  42.  Detailed  Breakdown  of  the  Template  Focused  on  Defining 
Crew  Positions 


El-  121 


Figure  43.  Flowchart  for  the  Task  Workload  Parameter  Input 
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Figure  44.  Flowchart  of  the  Overall  Process  of  Task  Parameter 
Estimation  Template 
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Figure  45.  Flowchart  of  the  Overall  Process  of  Task  Parameter 
Estimation  via  Comparable  Systems  Template 
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Figure  46.  Flowchart  of  the  Overall  Process  of  Task  Parameter 
Estimation  via  Subject  Matter  Experts  Template 
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Figure  47.  Flowchart  of  the  Overall  Process  of  Task  Parameter 
Estimation  via  Decomposition  Template 
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The  scenario  creation  template 


This  program  will  lead  the  analyst  through  the  creation  of 
scenarios  under  which  the  system  will  be  studied.  It  will  involve 
the  development  of  sequencing  relationships  among  operator  tasks 
and  the  addition  of  non-operator  tasks  (e.g. ,  threat  models)  should 
these  system  elements  need  to  be  modeled. 

In  constructing  a  scenario,  the  template  will  lead  the  analyst 
through  a  series  of  methods  for  selecting  and  defining  scenarios. 
The  overall  flowchart  for  this  template  is  presented  in  Figure  48. 
Figure  49  presents  a  flowchart  for  the  search  through  the  Scenario 
Library  for  similar  scenarios.  Figure  50  presents  a  flowchart  for 
the  definition  of  a  new  scenario. 

The  workload  diagnostics  decision  aid  template 

This  program  will  assist  the  analyst  in  defining  high  workload 
for  the  simulation  data  analysis.  Ultimately,  it  will  assist  the 
analyst  in  determining  whether  workload  was  excessive. 

Figure  51  presents  a  flowchart  for  the  development  of 
definitions  of  operator  overload.  Figure  52  presents  a  flowchart 
for  the  review  of  the  results  of  the  workload  analysis  data. 

Task  Performance  Requirement  Template 

This  template  will  lead  the  analyst  through  the  process  of 
determining  task  performance  requirements  for  individual  tasks  to 
assure  that  system  performance  is  satisfactory.  It  will  be  used 
when  the  analyst  determines  that  the  current  task  performance 
parameters  and  allocation  of  tasks  across  operators  results  in 
unacceptably  high  workload. 

The  focus  of  this  template  will  not  be  to  estimate  task 
performance  for  a  given  design  (this  is  the  job  of  the  Task 
Performance  Parameter  Estimation  Template) .  Rather,  this  template 
will  lead  the  analyst  through  the  process  of  finding  acceptable 
task  allocations  and  performance  levels  from  an  operator  workload 
perspective  for  the  design  to  satisfy  the  performance  requirements 
(identified  in  Product  1)  while  staying  within  the  manpower 
constraints  (identified  in  Product  2) .  This  template  will  be  used 
in  Step  10  as  discussed  in  Section  3.2.10. 

This  template  will  be  largely  a  decision  aid  since  the  actual 
process  of  revising  task  performance  requirements  or  reallocating 
tasks  across  operators  will  be  done  with  the  Function  and  Task 
Definition  Template  or  the  Scenario  Creation  Template.  The  Task 
Performance  Requirements  Template  will  lead  the  analyst  through  the 
process  of  1)  determining  the  appropriate  way  to  change  task 
requirements  (i.e.,  modify  operator  task  performances  or  reallocate 
tasks) ,  2)  considering  the  various 
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Figure  48.  Flowchart  for  Scenario  Definition  Template 
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Figure  49.  Flowchart  for  Search  Through  Scenario  Library 
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Figure  50.  Flowchart  for  Definition  of  a  New  Scenario 
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Figure  51.  Flowchart  for  the  Development  of  New  Scenarios 


Figure  52.  Flowchart  for  the  Review  of  the  Results  of  the  Workload 
Analysis 
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issues  that  should  be  addressed  for  each  approach,  3)  evaluating 
how  much  "change”  might  be  reasonable,  4)  determining  when  another 
operator  is  essential,  and  5)  deciding  when  the  system  design 
should  be  rejected  as  unable  to  be  operated  within  the  current 
manpower  constraints. 

3.3.2  The  Libraries 


The  Libraries  are  an  essential  concept  behind  our  approach. 

We  do  not  believe  that  it  would  be  reasonable  for  every  MANPRINT 
analysis  to  require  gathering  all  new  operator  task  and  scenario 
data.  There  are  many  aspects  of  any  new  system  which  are  analogous 
if  not  identical  to  existing  systems.  These  existing  systems  can 
provide  empirically-based  data  which  should  be  available  to  the 
users.  It  is  through  the  Libraries  that  these  data  will  be 
available. 

We  do  not  propose  that  we  will  be  able  to  develop  an  all 
inclusive  Task  or  Scenario  Library.  There  are  too  many  Army 
systems  and  potential  scenarios  to  consider  such  an  undertaking. 
Rather,  our  strategy  will  be  to  develop  portions  of  the  Library 
associated  with  1)  system  types  which  are  likely  to  require 
MANPRINT  analyses  in  the  near  future  and  2)  develop  at  least  one 
set  of  tasks  and  scenarios  for  each  of  the  13  mission  areas  defined 
in  Kaplan  and  Crooks  (1980) .  However,  embedded  in  the  Task  and 
Scenario  Development  Templates  (as  discussed  in  Section  3.3.1), 
will  be  the  opportunity  to  create  new  operator  tasks  and  scenarios 
reflecting  fielded  systems  that  were  not  previously  in  the 
Libraries.  As  the  analyst  collects  the  necessary  data  and  these 
files  become  validated,  they  can  be  added  to  the  appropriate 
Library. 

Let  us  now  discuss  each  of  these  Libraries  individually. 

Task  Library 

This  file  will  include  historical  data  on  operator  tasks 
sorted  by  mission  area  and  function.  The  information  that  will  be 
included  on  tasks  will  be  the  following: 

1 .  Task  name 

2.  Task  description 

3.  Associated  mission  area  (e.g.,  Armor) 

4.  Specific  system  type  (e.g.,  M-60) 

5.  Average  task  performance  time  under  normal  conditions 

6.  Standard  deviation  of  task  performance  time 
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7. 


Workload  requirements  in  the  four  workload  channels 
(visual,  auditory,  cognitive,  and  psychomotor) 


8.  Probability  of  making  an  error  in  performing  the  task 
(under  normal  conditions) 

The  above  data  will  be  gathered  from  the  sources  discussed  in 
Section  3.2. 

None  of  these  data  sources  will  provide  workload  data.  This 
information  will  be  added  to  the  library  by  the  review  of  the  files 
which  we  create  by  a  subject  matter  expert  from  the  Army  working 
with  a  psychologist  from  the  contractor  team.  Experience  has  shown 
that  these  two  individuals  working  together  can  quickly  assign 
valid  workload  values  to  a  large  number  of  tasks  which  will  then 
serve  as  guidance  to  analysts  using  the  system. 

Scenario  Library 

This  file  will  include  historical  data  on  mission  scenarios 
sorted  by  mission  area.  Scenarios  represent  the  sequences  of 
operator  tasks  and  conditions  related  to  specific  mission  types. 

The  information  that  will  be  stored  in  these  files  is  the 
following: 


1.  A  scenario  summary 

2 .  A  description  of  the  tactical  environment 

3 .  A  description  of  the  environmental  conditions  relevant  to 
performance  of  the  scenario 

4.  Inherent  task  sequencing  relationships  as  defined  by  a 
task  network  describing  task  interrelationships 

5.  Conditional  task  sequencing  describing  any  tasks  in  the 
scenario  whose  performance  is  conditional  on  other  tasks 
or  the  current  battlefield  conditions 

The  sources  for  the  above  data  are  the  same  as  those  data 
sources  for  the  Task  Library  as  described  in  Section  3.2. 

.? » 3->  3 _ Ihe_Fjles 

The  Files  are  created  by  the  analyst  during  the  study  of  a 
particular  system.  Therefore,  they  will  be,  in  essence,  created  by 
the  Templates  with  extensive  utilization  of  the  Libraries  as 
starting  points. 
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Task  Data  File 


This  file  will  include  all  data  which  the  analyst  creates 
defining  system  operator (s)  tasxs  within  each  function.  The 
information  stored  in  this  file  will  be  identical  to  the 
information  stored  on  each  task  in  the  Task  Library. 

Scenario  Data  File 


This  file  will  include  all  data  which  the  analyst  created 
regarding  specific  scenarios  under  which  system  operation  will  be 
studied.  The  information  stored  in  this  file  will  be  identical  to 
the  information  stored  on  each  scenario  in  the  Scenario  Library. 

3.3.4  The  Models 

The  Models  are  the  software  which  will  conduct  the  computer 
simulation  to  study  operator  workload  and  provide  the  analyst  with 
tools  for  data  analysis. 

The  Computer  Simulation  Model 

This  program  will  combine  the  task  and  scenario  data  files  and 
run  a  computer  simulation.  Output  of  this  simulation  will  include 
workload  levels  for  each  operator  at  predefined  time  intervals 
throughout  the  simulation  (e.g. ,  twice  a  second).  These  data  will 
be  used  by  the  workload  data  analysis  model. 

The  Workload  Data  Analysis  Model 

This  program  will  allow  the  analyst  to  review  workload  data 
generated  by  the  computer  simulation.  It  will  permit  him  to  review 
points  in  the  mission  where  workload  was  excessive  based  upon 
whatever  definition  of  "excessive”  he  chooses  to  use.  It  will  also 
generate  all  outputs  defined  in  Section  3.1.1. 


3.4  Estimated  Analysis  Time 

Based  on  an  operator  manning  analysis  defined  within  this 
section,  we  anticipate  that  a  range  of  40  -  100  hours  of  analyst 
time  will  be  required  for  a  typical  major  system  acquisition. 
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SECTION  4  -  MAINTENANCE  MANHOUR  ANALYSIS  AID  (MMAA) 


4 . 1  Overview 

This  module  of  the  MDA  provides  the  analyst  with  an  aid  for 
estimating  the  maintenance  requirements  of  a  proposed  system 
design  in  terms  of  the  number  of  jobs  required  to  maintain  the 
system,  the  number  of  people  required  per  job,  and  the 
maintenance  tasks  that  are  included  in  each  job.  The  ultimate 
goal  of  this  analysis  is  for  the  Army  to  determine  whether  the 
numbers  and  types  of  soldiers  required  to  maintain  the  proposed 
system  are  in  line  with  the  personnel  that  will  be  available  if 
the  design  is  funded. 

4.1.1  Differences  Between  Operator  and  Maintenance  Workload 

The  approach  for  determining  maintenance  requirements  using 
the  MMAA  differs  from  the  approach  for  determining  operator 
manpower  requirements  using  the  WAA.  The  reason  for  the 
difference  is  primarily  in  the  way  we  define  workload  for 
operators  versus  maintainers. 

Operators  of  a  military  system  are  often  required  to  perform 
a  number  of  different  tasks  simultaneously,  or  in  a  parallel 
fashion.  For  example,  a  tank  commander  must  listen  for  radio 
communication  at  the  same  time  he  is  visually  monitoring  both  the 
battlefield  for  threats  and  instruments  inside  the  tank.  While 
all  of  this  is  happening,  the  tank  commander  is  also  cognitively 
processing  all  of  the  information  he  is  receiving  through  the 
other  sensory  channels.  The  number  of  simultaneous  tasks  that 
can  be  performed  by  an  individual  operator  has  an  upper  limit 
beyond  which  the  operator  must  begin  dumping  some  tasks  to  be 
able  to  perform  others  or  decreasing  the  accuracy  with  which  each 
of  the  tasks  is  performed.  Either  qf  these  strategies  for  coping 
with  work  overload  is  potentially  detrimental  to  system 
effectiveness  and  the  survivability  of  the  operator  or  crew.  The 
distribution  of  tasks  (jobs)  for  operators  of  any  proposed  system 
should  be  designed  so  that  the  number  of  people  required  to 
operate  the  system  is  at  a  minimum  while  at  the  same  time  no 
individual  operator  is  assigned  more  tasks  than  he  can  perform 
effectively.  Therefore,  our  approach  for  determining  the 
manpower  requirements  for  operators  of  the  system  is  to  simulate 
the  sensory  channel  workload  requirements  for  each  operator  of 
the  system.  When  the  simulation  indicates  that  the  proposed 
allocation  of  tasks  to  jobs  results  in  excessively  high  workload 
for  an  operator,  it  means  that  the  average  operator  probably 
can't  do  the  job.  Therefore,  job  and  task  reallocation  is 
necessary  or  more  operators  are  necessary  to  reduce  the  workload 
to  acceptable  levels. 
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Maintenance  personnel  don't  perform  maintenance  tasks 
simultaneously.  They  work  in  more  of  a  serial  fashion.  Workload 
for  maintenance  activities  is  defined  in  terms  of  the  number  of 
maintenance  tasks  that  must  be  performed  in  the  allotted  time 
between  missions  and  how  many  people  it  takes  to  perform  all  of 
the  required  tasks.  When  a  maintenance  person  finishes  one 
task  the  next  task  is  started.  Therefore,  maintainers  are  not 
really  affected  by  sensory  overload  as  are  operators.  They  are 
however,  affected  by  the  number  of  maintenance  tasks  that  are  in 
the  queue.  For  example,  an  attack  helicopter  may  require 
maintenance  on  three  different  electrical  system  components 
before  it  can  be  used  on  the  next  scheduled  mission.  All  three 
tasks  are  within  the  scope  of  one  maintenance  job.  However,  if 
the  time  it  takes  to  perform  all  three  tasks  is  longer  than  the 
amount  of  time  before  the  next  scheduled  mission,  the  system  will 
not  be  available  to  perform  the  mission  unless  more  than  one 
person  is  assigned  to  that  maintenance  job. 

Another  important  distinction  between  operators  and 
maintainers  of  a  system  is  the  way  that  "jobs"  are  defined.  It's 
easy  to  see  that  assigning  jobs  in  terms  of  groups  of  tasks  to 
members  of  a  crew  that  will  operate  a  system  can  be  done  at  some 
initial  stage  of  system  design  without  regard  to  MOS,  skill,  or 
pay  grade.  This  works  because  operators  of  an  Army  system  are 
dedicated  to  that  system.  For  example,  soldiers  with  the  same 
MOS  can  be  assigned  different  jobs  as  members  of  a  gun  crew. 

Each  is  assigned  a  number  of  tasks  that  represent  part  of  the 
operation  of  the  system.  The  critical  questions  to  be  answered 
with  regard  to  manpower  requirements  for  the  operation  of  a 
system  are  (1)  What  tasks  should  be  assigned  to  what  jobs  so  that 
no  operator  has  more  than  he  can  effectively  do?  and  (2)  How  many 
of  each  job  are  necessary  to  ensure  optimal  workload? 

Maintenance  personnel,  on  the  other  hand,  are  not  dedicated 
to  a  single  system.  In  most  cases,  a  maintenance  person  is 
assigned  to  work  on  more  than  one  type  of  system  (e.g.  helicopter 
hydraulics  maintenance  rather  than  UH-60  hydraulics  maintenance) . 
As  a  result,  the  Army  doesn't  normally  assign  jobs  or  duty 
positions  to  maintenance  personnel  as  it  does  with  operators. 
Therefore,  maintenance  jobs  will  be  defined  for  the  MMAA  as  the 
combination  of  a  specific  MOS  and  skill  level  and  maintenance 
category.  The  analyst  will  be  able  to  define,  for  his  own 
analysis,  a  subset  of  this  definition.  For  example,  the  analyst 
may  want  to  consider  only  MOS  and  skill  level  without  regard  to 
maintenance  category  as  a  maintenance  "job". 

Maintenance  and  operator  workload  also  differ  in  the  time 
units  necessary  to  conduct  a  workload  analysis.  Operator 
workload  must  be  assessed  over  the  time  period  of  a  typical 
mission.  Maintenance  requirements  must  be  assessed  over  a  much 
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longer  period  (usually  one  year).  This,  combined  with  the  fact 
that  a  system  is  maintained  by  personnel  that  are  also  working  on 
other  systems,  is  the  reason  that  maintenance  requirements  are 
typically  measured  in  the  Army  in  terms  of  annual  maintenance 
manhours  per  maintenance  job. 

While  annual  maintenance  manhours  is  an  appropriate  way  to 
assess  maintenance  manpower  requirements,  it  can  be  misleading 
without  some  additional  information.  Annual  maintenance  manhours 
per  maintenance  job,  divided  by  the  number  of  hours  available  for 
a  single  maintainer  per  year  does  not  reflect  times  when  the 
number  of  maintenance  personnel  needed  for  a  particular  job  is 
greater  than  the  hours  would  indicate.  This  is  because  the 
ability  to  maintain  the  system  in  the  time  allotted  between 
missions  has  a  direct  result  on  system  availability.  Therefore, 
to  meet  the  system  availability  requirements,  it  may  be  necessary 
to  assign  more  than  one  person  to  perform  the  tasks  for  one 
maintenance  job,  even  though  the  annual  maintenance  manhours  are 
less  than  one  full-time  person. 

To  avoid  this  misinterpretation  of  annual  maintenance 
manhours  per  job,  the  MMAA  will  also  keep  track  of  the  actual 
number  of  people  required  to  maintain  the  system  and  the 
percentage  of  time  during  the  maintenance  period  that  number  were 
required.  For  example,  if  a  particular  system  has  an  annual 
maintenance  manhour  requirement  that  is  less  than  one  full  time 
maintenance  job,  based  on  annual  maintenance  manhours,  it  is  also 
important  for  the  analyst  to  know  that  40  %  of  the  maintenance 
time  over  the  period  being  analyzed,  it  required  two  people 
assigned  to  that  maintenance  job  to  ensure  system  availability. 

4.1.2  Theory  Behind  the  MMAA 

The  fundamental  assumption  for  the  MMAA  is  that  every  new  or 
modified  system  design  under  evaluation  is  comprised  of 
individual  hardware  and  software  components  that  need  to  be 
maintained  to  either  prevent  or  correct  a  malfunction  or  failure 
of  that  component.  The  rate  that  the  components  fail  or  need 
preventive  maintenance  is  different  for  every  component  and  is 
almost  always  directly  related  to  the  amount  of  use  that 
component  has  received  (realizing  that  there  are  components  that 
require  maintenance  purely  as  a  function  of  time  e.g.,  "lubricate 
joint") . 

Furthermore,  since  each  system  is  a  part  of  a  military 
mission,  there  is  only  a  limited  amount  of  time  available  for 
maintenance  of  system  components  without  taking  away  excessively 
from  the  system's  availability  to  perform  missions.  Therefore, 
if  we  can  estimate  parameters  that  describe  the  maintenance 
requirements  for  each  component  and  parameters  that  describe  the 
usage  rate  for  each  component,  we  can  feed  that  information  into 
a  generic  maintenance  manning  simulation  model  to  calculate  the 
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maintenance  manpower  requirements  for  the  overall  system.  In 
general  terms,  component  maintenance  parameters  include: 

•  The  rate  at  which  each  component  requires  maintenance. 

•  The  maintenance  action (s)  required. 

•  The  time  it  takes  to  perform  the  maintenance. 

•  The  type  of  person  required  to  perform  the  maintenance 
(i.e.,  MOS,  Skill  level  and  Category). 

A  more  detailed  discussion  of  the  specific  component 
maintenance  parameters  is  included  in  Section  4.2.1  on  page  150. 

Again  in  general  terms,  the  component  usage  parameters 
include: 

•  The  usage  rate  for  each  component  per  mission. 

•  The  average  length  of  a  mission. 

•  The  frequency  of  missions. 


A  more  detailed  discussion  of  the  specific  component  usage 
parameters  is  included  in  Section  4.2.5  on  page  175. 

4.1.3  Overview  of  the  MMAA  Approach 

The  backbone  of  the  MMAA  will  be  a  maintenance  manning 
network  simulation  model  similar  in  function  to  that  of  the 
Logistics  Composite  Model  (LCOM)  developed  for  the  Air  Force. 
However,  this  model  differs  from  LCOM  in  that  it  is  embedded 
within  the  MMAA  and  does  not  require  the  analyst  to  develop  any 
of  the  complex  modeling  logic  required  by  LCOM.  Another 
advantage  of  the  simulation  model  developed  for  the  MMAA  is  that, 
rather  than  treating  maintenance  as  a  portion  of  the  overall 
logistics  support  analysis,  it  is  designed  specifically  for 
evaluating  a  particular  system  design  in  terms  of  the  maintenance 
jobs  that  are  required,  the  number  of  personnel  required  for  each 
maintenance  job,  and  the  specific  maintenance  actions  or  tasks 
that  comprise  each  maintenance  job. 

While  the  backbone  of  the  MMAA  is  the  simulation  model,  the 
major  focus  of  the  aid  is  to: 

•  provide  Army  analysts  with  access  to  data  that  will 
assist  them  in  estimating  the  component  maintenance 
requirements  of  the  system  design  under  evaluation. 
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•  provide  analysts  with  guidance  in  estimating  and 
entering  component  maintenance  parameters  and  system 
usage  rates  needed  as  input  to  the  simulation  model  for 
each  potential  mission  scenario  required  of  the 
proposed  new  or  modified  design. 

•  To  provide  the  analyst  with  mechanisms  for  retrieving, 
organizing,  and  interpreting  outputs  of  the  simulation 
with  respect  to  the  maintenance  jobs  that  are  required, 
the  tasks  are  assigned  to  each  job,  and  the  number  of 
people  that  are  needed  for  each  maintenance  job. 

The  approach  used  by  the  MMAA  for  determining  maintenance 
jobs,  number  of  maintainers  per  job,  and  maintenance  tasks  per 
job  is  to  model  the  overall  maintenance  requirements  for  the 
system  based  on  the  expected  failure  rates  or  planned  maintenance 
schedules  of  each  system  hardware  and  software  component,  mission 
scenario  system  usage  rates,  and  the  time  it  takes  to  perform 
each  maintenance  task. 

The  process  of  determining  maintenance  requirements  for  a 
new  or  modified  system  design  consists  of  four  general 
activities.  The  first  is  to  identify  the  most  accurate  estimate 
possible  of  the  maintenance  parameters  for  each  hardware  or 
software  component  in  the  contractor's  design.  Table  4  contains 
a  list  of  the  Component  Maintenance  Parameters  that  will  be  used 
by  the  MMAA  simulation  model  to  calculate  how  often  each 
component  needs  maintenance,  the  maintenance  task  required,  and 
who  should  perform  the  maintenance. 

The  next  activity  for  the  analyst  is  to  identify  parameters 
for  each  potential  mission  scenario  required  of  the  proposed  or 
modified  system.  This  data  will  be  used  to  determine  the  usage 
rates  for  each  of  the  system  components  and  to  determine  the 
"window"  of  time  available  for  maintenance  between  missions. 

Table  5  contains  a  list  of  the  Mission  Scenario  Parameters. 

These  parameters  will  be  used  by  the  MMAA  to  model  component 
breakdown  or  malfunction  and  planned  maintenance. 

The  third  general  activity  is  for  the  analyst  to  exercise 
the  computer  simulation  model  that  is  embedded  in  the  (MMAA)  to 
calculate  the  maintenance  manpower  requirements  for  the  overall 
system. 

The  last  activity  is  to  analyze  and  evaluate  the  results  of 
the  simulation  model  and  to  investigate  potential  solutions  to 
maintenance  deficiencies. 
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Table  4  Component  Maintenance  Parameters 


The  name  of  the  component 

The  maintenance  action  to  be  performed 

The  MOS  and  skill  level  needed  to  perform  the 
maintenance 

Maintenance  type  (e.g.  planned,  corrective) 

Mean  operational  units  between  failure  of  the  component 
(e.g.,  time,  rounds  fired,  flight  hours,  etc.) 

The  maintenance  category  (e.g.,  org,  ds,  gs,  depot) 

Mean  times  and  standard  deviations  for  maintenance 
actions 

Maintenance  accuracy  (for  diagnose  or  troubleshoot 
activities) 

An  indication  of  whether  or  not  the  failure  of  each 
component  could  result  in  a  mission  being  aborted 

The  operational  conditions  (e.g.,  terrain,  weather, 
threats,  etc.)  that  are  represented  by  the  data  in  the 
component  library 
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Table  5  -  Mission  Scenario  Parameters 

•  Simulation  Period 

•  Number  of  Missions  per  Day 

•  Mission  Length 

•  Mission  Frequency 

•  Operational  Units  per  Mission  for  each  Component 


4.1.4  Steps  the  Analyst  Will  Follow  in  Using  the  MMAA 

In  applying  the  MMAA,  the  -four  general  activities  described 
above  are  further  broken  down  into  eight  steps  that  the  analyst 
will  perform.  Section  4-2  contains  a  detailed  discussion  of  each 
of  the  eight  steps  involved  in  using  the  MMAA.  Following  is  a 
brief  description  of  each  step  (page  number  references  for  the 
detailed  explanation  in  Section  4-2  are  included) : 

1.  Enter  the  system  components  and  all  available 
maintenance  parameters  from  the  contractor's  design, 
(see  page  El-150) 

2 .  Match  system  components  and  parameters  from  the 
contractor's  design  to  baseline  estimates  from 
comparable  systems.  (see  page  El-157) 

3.  Identify  discrepancies  between  the  government  baseline 
estimates  and  the  contractor's  design  estimates  of 
component  maintenance  parameters.  (see  page  El-169) 

4 .  Resolve  the  discrepancies  to  determine  the  "best 
estimates"  of  component  maintenance  parameters.  (see 
page  El-172) 

5.  Identify  and  develop  parameters  for  each  mission 
scenario  to  be  analyzed  in  terms  of  maintenance  manhour 
requirements.  (see  page  El-175) 
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6.  Exercise  the  computer  simulation  to  calculate  the 
maintenance  manhour  requirements,  system  availability, 
and  system  reliability  for  each  mission  scenario.  (see 
page  El-180) 

7.  Evaluate  the  results  of  the  computer  simulation  in 
terms  of  the  maintenance  jobs  that  are  required,  the 
tasks  that  make  up  each  job,  the  number  of  maintenance 
hours  required  per  job,  system  performance  requirements 
and  manpower  constraints.  (see  page  El-182) 

8 .  Investigate  potential  solutions  to  maintenance 
deficiencies  by  modifying  component  maintenance 
parameters  and  re-running  the  model  to  determine  the 
effect  on  system  reliability,  availability,  and 
maintenance  manpower  requirements.  (see  page  El-184) 

Figure  53  is  an  illustration  of  the  sequential  flow  of  the 
eight  steps  that  the  analyst  will  follow. 

4.1.5 _ Outputs 

Each  time  the  analyst  executes  the  Maintenance  Requirements 
Simulation  Model  that  is  embedded  within  the  MMAA,  the  model  will 
calculate  a  variety  of  data  that  will  be  stored  in  a  simulation 
results  file  for  that  particular  mission  scenario.  This  results 
file  will  serve  as  a  relational  data  base  of  maintenance 
requirements.  Using  the  Reports  Generator,  described  in  Section 
4.3  page  185,  the  analyst  will  be  able  to  display  or  obtain  a 
hard  copy  of  a  simulation  results  summary  report.  The  summary 
report  will  consist  of  a  table  of  information  that  contains  the 
following  information  for  each  maintenance  job  (MOS,  Skill  level 
and  Category)  that  was  entered  as  a  Component  Maintenance 
Parameter : 

•  All  of  the  maintenance  actions  (tasks)  that  were 
assigned  to  the  maintenance  job. 

•  The  number  of  times  each  task  was  performed. 

•  The  total  number  of  maintenance  hours  for  each  task. 

•  The  total  number  of  maintenance  hours  for  each 

maintenance  job. 
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Figure  53.  Steps  in  Using  the  Maintenance  Manhour  Analysis  Aid 
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In  addition  to  the  report  of  maintenance  manhours  for  each 
maintenance  job,  the  MMAA  Reports  Generator  will  also  produce  a 
histogram  of  the  actual  number  of  maintainers  needed  for  each 
maintenance  job  and  the  percentage  of  the  total  maintenance  time 
each  number  was  needed.  For  example,  the  total  number  of  annual 
maintenance  manhour.'  for  a  particular  maintenance  job  may  be  only 
1355,  which  is  less  than  one  full  time  maintainer.  However,  due 
to  the  maintenance  windows  that  are  imposed  because  of  the 
system's  need  to  perform  missions,  the  histogram  may  show  that, 
for  70  %  of  the  maintenance  time  during  that  period,  2  people 
were  required.  Figure  54  is  an  illustration  of  a  histogram  of 
maintenance  headcount  requirements. 

The  analyst  will  also  be  able  to  use  the  Reports  Generator 
to  extract  and  report  any  other  combinations  of  data  contained  in 
the  simulation  results  data  base.  Following  is  a  list  of  some 
of  the  other  results  contained  in  the  data  base: 

e  The  number  of  times  a  mission  was  missed  due  to 
maintenance. 

e  The  percentage  of  time  the  system  was  available  when 
needed  for  a  mission. 

e  The  percentage  of  time  a  mission  had  to  be  aborted  for 
maintenance. 

For  more  detailed  information  on  the  outputs  of  the  MMAA, 
refer  to  Section  4.2.7  on  page  El-182,  and  Section  4.3.2  page  El- 
188. 

4.1.6  Automated  Components  for  the  MMAA 

The  software  elements  that  comprise  the  Maintenance  Manhour 
Analysis  Aid  (MMAA)  are  grouped  into  the  following  categories: 

1.  Templates  -  consist  of  sets  of  menus,  prompts,  and 
spreadsheet-like  interfaces  for  users  to  create  and 
gain  access  to  data  files  and  military  data  bases. 

2.  The  Component  Maintenance  Parameter  Library  -  includes 
historical  data  on  maintenance  parameters  of  fielded 
military  weapon  systems. 

3 .  Direct  Access  to  Military  Maintenance  Data  Bases  - 
Although  not  formally  an  MMAA  software  component,  we 
will  develop  communication  software  that  will  allow  the 
analyst  to  access  selected  maintenance  historical  data 
bases  of  fielded  systems,  such  as  the  Sample  Data 
Collection  Data  Base,  to  assist  the  analyst  in 
determining  Component  Maintenance  Parameters. 
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Figure  54.  Histogram  of  Maintenance  Headcount  Requirements 
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4. 


Data  files  -  store  information  specific  to  the 
evaluation  of  a  proposed  system  design.  Data  files 
store  both  input  and  output  data  that  is  used  and 
produced  by  the  other  software  components. 

5.  The  Maintenance  Requirements  Simulation  Model  -  is  the 
generic  maintenance  network  simulation  model  used  to 
calculate  estimated  maintenance  manpower  requirements. 

Like  the  WAA,  the  MMAA  will  have  an  Application  Manager  that 
is  the  underlying  software  operating  system  that  controls  the 
transfer  of  information  between  all  of  the  software  components. 

The  nature  of  the  these  five  software  elements  is 
essentially  the  same  as  those  discussed  for  the  WAA  in  Section 
3.1.3. 


4.1.7  Overview  of  Approach  for  Product  Development 

The  approach  to  product  development  will  mirror  the  approach 
for  the  WAA.  This  is  discussed  in  detail  in  Section  3.1.4,  but 
let  us  repeat  the  highlights  of  the  approach  below. 

Virtually  all  of  this  aid  will  be  automated  with  the 
exception  of  some  basic  documentation  to  "get  the  analyst 
started."  Therefore,  let  us  discuss  product  development  in  the 
context  of  the  development  of  the  five  categories  of  software 
described  above. 

The  four  sets  of  software  which  will  need  to  be  developed  as 
part  of  product  development  are  the  Templates,  the  Component 
Maintenance  Parameter  Library,  the  software  to  provide  direct 
access  to  maintenance  data  bases,  and  the  Maintenance 
Requirements  Simulation  Model.  The  fifth  set  of  software,  the 
Files,  will  be  created  by  analysts  as  they  use  the  MMAA.  Let  us 
briefly  discuss  the  development  of  the  Templates,  Component 
Maintenance  Parameter  Library,  direct  access  to  military 
maintenance  data  bases,  and  Maintenance  Requirements  Simulation 
Model  individually.  More  detail  on  each  of  these  is  presented  in 
Section  4-3. 

The  Templates  -  As  we  stated  earlier,  the  underlying 
software  which  will  support  the  use  of  computer  simulation  is 
Micro  SAINT.  We  will  use  the  power  of  Micro  SAINT  model 
execution  and  data  generation  but  will  develop  specific  model 
development  software  aimed  directly  at  maintenance  manning 
analysis.  Therefore,  rather  than  a  general  model  development 
interface  as  currently  exists,  we  will  have  a  very  "MMAA 
specific"  interface. 
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In  this  task,  we  have  identified  preliminary  user  steps  and 
user  interfaces.  We  emphasize  that  the  user  interfaces  are 
preliminary,  intended  more  to  illustrate  ideas  and  clarify  points 
than  to  provide  specific  interfaces.  In  Task  2  of  this  effort, 
we  will  develop  specific  user  scripts  which  will  be  submitted  to 
users  for  comments.  Additionally,  we  will  develop  data  flow 
diagrams  linking  user  interfaces  to  the  generation  of  the  Files 
which  will  be  used  in  the  analysis. 

The  Component  Maintenance  Parameter  Library  -  Our  basic 
philosophy  for  developing  the  library  will  be  to  construct  a  set 
of  entries  for  Component  Maintenance  Parameters  for  fielded 
systems  into  the  library  during  Task  3  of  this  effort.  This  set 
will  be  selected  so  that  it  represents  the  mission  areas  which 
are  likely  to  require  MANPRINT  analyses  in  the  near  future  based 
on  existing  requirements.  Additionally,  we  will  embed  mechanisms 
into  the  software  for  adding  task  and  scenario  files  to  the 
libraries  as  users  conduct  MANPRINT  analyses  on  new  systems.  In 
doing  this,  analysts  will  be  able  to  create  their  own  files 
representing  a  new  system  and  then,  if  appropriate,  add  that  file 
to  the  library.  In  essence,  we  propose  to  develop  enough  pieces 
of  the  library  to  bootstrap  the  use  of  this  tool.  Then,  as  the 
aid  is  used,  the  libraries  will  grow  reflecting  new  system 
designs. 

In  Task  2  of  this  effort  (development  of  detailed  design 
specifications),  we  will  develop  data  base  formats  (e.g. ,  field 
definitions,  record  lengths)  as  well  as  software  for  the  creation 
and  management  of  these  libraries.  Additionally,  we  will  finally 
define  all  data  sources  for  the  specific  entries  into  the 
libraries  to  be  developed  in  Task  3  of  this  effort. 

Finally,  in  Task  3,  we  will  develop  the  library  management 
software  and  construct  the  subsets  of  the  libraries  defined  in 
Task  2. 

Direct  Access  to  Military  Maintenance  Data  Bases  -  To 
supplement  the  Component  Maintenance  Parameter  Library,  we  will 
develop  the  software  to  allow  the  analyst  to  access  military 
maintenance  data  bases,  such  as  the  Sample  Data  Collection  Data 
Base,  that  reside  outside  of  the  MMAA.  DRC  currently  maintains  a 
direct  link  to  the  SDC  Data  Base.  Although  these  data  bases 
will  not  be  considered  a  formal  part  of  the  MMAA,  the 
communication  and  data  conversion  software  we  develop  will  use 
the  concept  of  "software  windows"  to  access  the  data  base  without 
leaving  the  MMAA.  The  software  that  we  develop  to  give  the 
analyst  access  to  maintenance  data  bases  will  also  include  user 
interfaces  that  are  consistent  with  the  other  components  of  the 
MMAA.  The  analyst  will  be  able  to  query  the  data  bases  from  a 
menu  and  prompt  driven  interface  that  is  a  part  of  the  MMAA 
rather  than  being  forced  to  use  the  data  base  query  languages 
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that  are  required  by  the  data  bases  themselves.  The  analysts 
will  use  these  data  to  help  identify  Component  Maintenance 
Parameters  for  comparable  systems  that  don't  reside  in  the 
Component  Maintenance  Parameter  Library. 

In  Task  2  of  this  effort,  we  will  identify  the  data  bases 
for  which  direct  access  will  be  provided  and  develop  detailed 
software  specifications.  Finally,  in  Task  3  we  will  complete  all 
software  development,  debugging,  and  operational  testing  of  the 
software. 

The  Maintenance  Requirements  Simulation  Model  -  As  was 
stated  in  the  discussion  of  Templates,  the  basis  for  all  models 
will  be  Micro  SAINT.  Again,  however,  the  analyst  will  not  "see" 
Micro  SAINT,  he  will  not  "execute"  Micro  SAINT  models,  nor  will 
he  "analyze"  Micro  SAINT  data  in  the  ways  that  a  user  of  Micro 
SAINT  would.  Rather,  by  creating  Component  Maintenance  Parameter 
files  and  Mission  Scenario  files,  the  analyst  will  have  created 
all  of  the  information  necessary  for  the  simulation.  Our 
modeling  software  will  create  Micro  SAINT  models  directly  from 
these  files,  execute  them,  collect  the  appropriate  data,  and  then 
analyze  the  data,  all  in  the  specific  context  of  maintenance 
manning  analysis. 

In  Task  2  of  this  effort,  we  will  develop  detailed  software 
specifications  and,  in  fact,  we  expect  to  be  able  to  begin  some 
coding  within  the  available  time.  Finally,  in  Task  3  we  will 
complete  all  software  development,  debugging,  and  operational 
testing  of  the  models. 


4.2  Detailed  Discussion  of 
the  Steps  Followed  bv  the  Analyst  Using 
the  Maintenance  Manhour  Analysis  Aid  (MMAA) 

The  purpose  of  this  module  of  the  Manpower  Determination  Aid 
(MDA)  is  to  assist  the  analyst  in  evaluating  initial  contractor 
designs  during  the  proof  of  principal  phase  of  the  acquisition 
process  by  estimating  the  maintenance  workload  required  to 
maintain  the  system.  Workload  is  specified  in  terms  of  the 
maintenance  jobs  that  are  required  (MOS,  skill  level  and 
Category),  the  number  of  jobs,  and  the  maintenance  actions  or 
tasks  per  maintenance  job.  The  overall  outputs  obtained  from  the 
use  of  this  aid  will  be  evaluated  in  terms  of  the  manpower 
constraints  for  maintenance  workload  (i.e.,  AMMH)  that  are 
determined  during  the  system  requirements  specification  phase  of 
the  acquisition  process. 

The  MMAA  guides  the  analyst  through  the  process  of  defining 
component  maintenance  parameters  and  system  usage  rates  for  each 
potential  mission  scenario  required  of  the  proposed  or  modified 
system  through  the  use  of  menus,  prompts,  templates,  a  Component 
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Maintenance  Parameter  Library,  and  military  maintenance 
historical  data  bases.  The  analyst  can  then  exercise  the 
computer  model  to  calculate  the  maintenance  requirements  for  the 
overall  system. 

The  analyst  will  compare  the  results  of  the  simulation  with 
the  output  of  the  System  Performance  Requirements  Estimation  Aid 
(SPREA)  developed  in  product  1  and  the  Manpower  Constraints 
Estimation  Aid  (MCEA)  developed  in  product  2  to  evaluate  the 
system  design  for  maintenance  deficiencies. 

The  MMAA  can  also  be  used  as  a  tool  to  simulate  potential 
solutions  to  maintenance  deficiencies  such  as  the  effects  of 
increased  component  reliability  or  decreases  in  mean  repair  times 
on  overall  system  maintenance  workload. 

The  next  sections  of  this  concept  paper  will  discuss  in 
detail  each  of  the  eight  steps  the  analyst  will  follow  to  use  the 
MMAA  (listed  in  section  4.1.2).  For  each  step,  we  will  include 
the  required  input  data,  data  sources,  the  process  for  performing 
the  step,  the  software  interfaces  associated  with  the  automated 
portions  of  the  process,  and  the  output  of  the  step. 

4.2.1  Step  1  Enter  the  system  components  and  all  available 

maintenance  parameters  from  the  contractors 
design. 

Input 


Internal  -  The  input  for  this  step  that  is  included  within 
the  MMAA  are  the  Component  Maintenance  Parameter  templates.  The 
development  procedures  and  data  sources  for  the  templates  are 
discussed  in  detail  in  section  4.3  of  this  concept  paper. 

External  -  As  a  part  of  the  contractor's  Logistic  Support 
Analysis  Record,  they  should  conduct  a  task  analysis  to  indicate 
the  quantitative,  qualitative,  and  procedural  requirements  for 
all  planned  and  corrective  maintenance  activities  for  each  system 
component.  The  results  of  the  LSA  will  be  documented  in  the 
LSAR.  The  contractor's  design  will  indicate  all  of  the  system 
components  and  sub-components.  A  schedule  of  planned  maintenance 
activities  should  indicate  the  operational  units  between  each 
planned  maintenance  action  such  as  the  number  of  miles  traveled, 
time,  or  rounds  fired.  As  a  part  of  the  LSA,  the  contractor 
should  supply  reliability  information  indicating  the  mean 
operational  units  between  failure  for  each  component  and 
information  on  the  frequency  distribution  of  the  failures.  The 
contractor's  design  may  also  indicate  whether  or  not  the  failure 
of  a  particular  component  would  cause  a  mission  to  be  aborted. 
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In  addition  to  the  LSAR,  other  maintenance  task  information 
may  be  available  in  separate  task  analyses  conducted  for  training 
or  for  human  factors  analyses.  The  latter  would  be  documented  in 
the  Human  Engineering  Design  Analysis  Document  for  Maintenance 
(HEDAD-M) . 

The  maintenance  task  analysis  should  indicate  maintenance 
actions  for  both  planned  and  corrective  maintenance  for  each 
system  component. 

Following  is  a  sample  list  of  typical  maintenance  actions 
(Kaplan  and  Crooks  1980) : 

inspect 

lubricate 

fill 

drain 

purge 

paint 

clean 

remove  or  change  or  replace 
troubleshoot  or  diagnose 
repair 

disassemble  or  assemble 
install 

adjust  or  align 
test 

For  each  maintenance  action,  the  task  analysis  may  include 
the  following  information: 

•  mean  and  standard  deviation  of  time  to  repair 

•  maintenance  category 

crew 

-  organizational 

-  direct  support 

-  general  support 
depot 

•  the  number  of  each  MOS  and  skill  level  required 

•  tools  and  equipment  needed 

•  special  requirements  for  maintainers  (e.g.  height, 
security  clearance) 


NOTE:  This  description  of  input  data  to  be  obtained  from 
the  contractor's  design  documentation  and  maintenance  task 
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analysis  represents  a  "best  case”  situation.  In  reality,  the 
contractor  may  supply  only  a  portion  of  this  information.  At  the 
very  least,  however,  the  design  should  include  a  list  of  the 
individual  system  components.  The  process  for  using  the  MMAA 
takes  into  consideration  design  documentation  that  contains  only 
a  minimal  amount  of  maintenance  task  information. 

Process 


The  first  four  steps  in  the  process  of  utilizing  the  MMAA 
are  all  aimed  at  obtaining  the  best  available  estimates  of  the 
maintenance  parameters  needed  as  input  for  the  Maintenance 
Requirements  Simulation  Model  for  each  hardware  or  software 
component  in  the  system  design.  Table  4  on  page  141  lists  each 
of  the  Component  Maintenance  Parameters.  Step  1  of  this  four 
step  process  is  for  the  analyst  to  enter  all  of  the  components 
from  the  system  design  and  as  many  of  the  maintenance  parameters 
for  each  component  as  are  available  in  the  design  documentation 
into  a  Component  Maintenance  Parameter  Template.  The  analyst 
begins  this  step  by  accessing  the  MAINTENANCE  MANPOWER  ANALYSIS 
AID  main  menu.  Figure  55  is  an  example  of  what  that  menu  might 
look  like. 

From  the  MMAA  main  menu,  the  analyst  can  enter  the  name  of 
the  major  system  whose  design  is  being  evaluated.  When  the 
analyst  selects  the  "Component  Maintenance  Parameters"  option 
from  the  main  menu,  a  screen  similar  to  the  one  shown  in  Figure 
56  will  display  a  list  of  all  of  the  functional  systems  within 
the  major  system  being  evaluated  that  have  been  entered  so  far. 

A  functional  system  is  defined  as  a  group  or  set  of  components 
that  perform  a  function  within  the  overall  system  (e.g.,  avionics 
system,  cooling  system,  engine,  etc.).  System  components  and 
their  associated  maintenance  parameters  are  entered  into 
Component  Maintenance  Parameter  Templates  by  functional  system. 

From  the  functional  system  listing,  the  analyst  can  enter 
simple  one-letter  commands  to  add,  modify,  delete,  copy,  or  save 
functional  systems. 

When  the  analyst  chooses  to  add  a  functional  system,  a 
prompt  will  be  displayed  asking  the  analyst  to  enter  a  name  for 
the  new  functional  system.  When  the  analyst  enters  a  name,  a 
Component  Maintenance  Parameter  Template,  similar  to  the  one 
shown  in  Figure  57  will  be  displayed. 
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1. 


Maintenance  Manhour  Analysis  Aid  Main  Menu 
System  Name  In  Memory:  M60  Tank 

2.  Develop  Component  Maintenance  Parameters 

3.  Develop  Mission  Scenario 

4.  Execute  Maintenance  Simulation 

5.  Analyze  Simulation  Results 

6.  List  Current  Systems 

Enter  a  number  and  then  press  <RETURN>_ 


Figure  55.  Maintenance  Manhour  Analysis  Aid  Main  Menu 
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Working  File  Listing  of  Functional  Systems 


Functional  Systems 
Major  System:  M60  Tank 

1.  Armament  System 

2 .  Engine 

3 .  Communications 

4. 

5. 


Command  (a,  m,  d,  c,  s):_ 

add  =  add  functional  system  components  using  a  blank  template 
modify  *  display  existing  functional  system  template 
delete  =  delete  a  template 

copy  *  copy  a  template  from  the  Library  or  another  working  file 
save  =  save  all  changes  made  to  this  working  file 


Figure  56.  Listing  of  Functional  Systems 
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Major  System:  M60Tank 


Functional  System:  Engine 


Maintenar 

Action 


adj  ust 


repai  r 


Fuel 

Injection 


Cylinder 

Head 


Crankshaft 


Seals,  main 


Mean 

Units 

Betveen 

Failure 

Mean  Time 
to  Repair 
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1020 
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Baseline 

Estimates 


Contractor 
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Figure  57.  Component  Maintenance  Parameters  Template 
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The  Component  Maintenance  Parameter  Template  is  a  matrix  of 
rows  and  columns  of  cells  with  an  interface  much  like  that  of  an 
electronic  spreadsheet.  In  the  left-most  column  of  the 
template,  the  analyst  will  enter  the  names  of  the  functional 
system  components  directly  from  the  contractor's  design.  The 
rows  of  cells  to  the  right  of  the  component  names,  will  contain 
the  maintenance  parameter  entries  for  each  component.  The  top 
row  contains  the  column  headings  representing  each  of  the 
component  maintenance  parameter. 

Each  cell  of  the  spreadsheet  is  divided  into  two  sections. 
The  top  portion  of  the  cell  will  eventually  contain  the  Army's 
estimate  for  each  Component  Maintenance  Parameter.  The  bottom 
portion  of  each  cell  is  reserved  for  the  contractor's  estimate, 
if  it  is  available.  As  the  analyst  enters  the  component  name 
from  the  design,  he  or  she  will  also  enter  any  of  the  maintenance 
parameters  that  are  included  in  the  design.  While  it  is  unlikely 
that  the  contractor  will  include  all  of  the  maintenance 
parameters  in  the  design,  it  is  likely  that  some  will  be 
available.  The  contractor's  estimates  of  maintenance  parameters 
will  be  compared  to  Army  estimates  later  in  the  analysis  process. 
The  reason  for  this  is  that,  even  in  the  design  of  a  new  weapon 
system,  probably  not  every  component  in  every  functional  system 
is  an  entirely  new  design.  Therefore,  the  maintenance  parameters 
for  some  of  the  components  may  be  clearly  understood  by  both  the 
Army  and  the  contractor.  In  cases  where  both  the  Army  and  the 
contractor  agree  on  a  component  maintenance  parameter,  it  is 
probably  safe  to  assume  that  it  is  the  best  available  estimate. 

The  analyst  will  continue  this  process  of  entering 
components  and  the  available  parameters  from  the  system  design 
until  the  components  for  all  of  the  functional  systems  have  been 
entered. 

Output 

The  output  of  this  step  is  a  set  of  matrices  containing  the 
names  of  the  hardware  or  software  components  in  each  functional 
system  of  the  design  being  evaluated  and  the  contractor's 
estimates  of  component  maintenance  parameters.  These  matrices 
will  be  stored  in  the  Component  Maintenance  Parameter  File. 

There  may  be  some  data  missing  from  the  contractor  estimates  due 
to  missing  information  in  the  system  design  documents. 

User  Interface  Issues 

The  user  interfaces  for  entering  the  component  names  and 
maintenance  parameters  by  functional  system  from  the  system 
design  will  consist  primarily  of  menus,  prompts,  simple  one 
letter  commands,  and  spreadsheet-like  templates.  Context 
specific  help  will  be  available  to  the  analyst  at  all  points 
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during  the  process. 

The  actual  design  of  menus,  selection  procedures,  and 
keyboard  routines  will  be  developed  based  on  input  from  intended 
users,  human  factors  analysis,  and  the  final  software  design. 


4.2.2  Step  2  Match  baseline  estimates  to  system  components  and 

parameters  from  the  contractors  design. 


Input 


Internal  The  input  for  this  step  that  is  included  within 
the  MMAA  will  be  1)  Component  Maintenance  Parameter  Files 
containing  the  names  of  each  hardware  or  software  component  by 
functional  system  created  in  Step  1,  2)  the  Component  Maintenance 
Parameter  Templates  for  development  of  estimates  of  component 
maintenance  parameters  that  are  based  on  parameters  of  comparable 
fielded  systems  and  3)  the  Library  of  component  maintenance 
parameters  for  selected  fielded  systems. 

The  development  procedures  and  data  sources  for  the 
templates  and  the  library  of  component  maintenance  data  for 
fielded  systems  are  discussed  in  detail  in  Section  4.3  of  this 
concept  paper. 

External 

•  Army  Annual  Maintenance  Manhours  Data  Base  (AMMDB) 

•  Sample  Data  Collection  System  Data  Base 

•  Army  equipment  inventories  of  fielded  systems 

•  System  design  specifications  for  fielded  systems 

•  Technical  Manuals  for  maintenance  activities 

•  Subject  Matter  Experts 


Process 

The  process  of  identifying  baseline  estimates  of  system 
component  maintenance  parameters  is  dependent  on  the  availability 
of  fielded  system  data  within  the  Library  of  component 
maintenance  parameters.  During  the  development  of  the  MMAA,  we 
will  develop  component  maintenance  parameter  data  for  a  selected 
number  of  fielded  systems  in  different  mission  areas.  These  data 
will  reside  in  the  Library  that  can  be  accessed  by  the  analyst. 
However,  it  will  not  be  possible  to  develop  baseline  data  for 
every  type  of  major  weapon  system  in  every  mission  area. 
Therefore,  in  cases  where  a  data  from  suitable  baseline  system 
does  not  exist  in  the  Library  for  the  system  being  evaluated,  the 
analyst  will  need  to  identify  the  component  maintenance 
parameters  for  a  similar  system  from  other  available  sources. 


El-157 


Upon  completion  of  the  component  maintenance  parameter 
identification  process,  the  analyst  will  have  created  a  file 
containing  baseline  data  and  possible  contractor  estimates  to  use 
as  a  starting  point  for  determining  the  best  available  estimates 
of  the  component  maintenance  parameters  of  the  proposed  new  or 
modified  system. 

We  anticipate  that  as  the  use  of  the  MMAA  expands,  the 
inventory  of  maintenance  data  for  major  systems  in  the  Component 
Maintenance  Parameter  Library  will  continue  to  grow.  When  a 
system  design  is  ultimately  approved  and  fielded,  the  baseline 
estimates  of  component  maintenance  parameters  that  are  used  for 
the  manhour  requirements  analysis  can  be  updated  with  actual 
usage  data  and  added  to  the  library. 

The  process  of  identifying  baseline  system  component 
maintenance  parameters  will  therefore  be  discussed  in  terms  of 
situations  when  1)  a  suitable  system  in  the  baseline  library  does 
exist  and  2)  when  the  analyst  must  identify  new  baseline 
estimates. 

Selecting  Components  from  the  Baseline  Library 

From  the  Component  Maintenance  Parameter  Template,  the 
analyst  will  be  able  to  create  software  '’windows"  for  access  to 
the  Component  Maintenance  Parameter  Library  to  search  for 
comparable  system  components  used  in  fielded  systems.  Defining 
the  software  windows  and  accessing  the  library  will  be 
accomplished  through  the  use  of  embedded  menus  similar  to  the 
ones  used  by  commercial  spreadsheet  packages  and  word  processing 
software. 

Once  the  analyst  has  gained  access  to  the  library,  he  or  she 
can  search  for  comparable  system  components  and  copy  the 
maintenance  parameters  into  the  template  by  switching  back  and 
forth  from  the  library  window  to  the  Component  Maintenance 
Parameter  Template  window. 

When  the  analyst  is  working  in  the  library  window,  a  series 
of  menus  will  allow  him  or  her  to  converge  on  system  components 
of  the  fielded  systems  contained  in  the  library. 

The  MMAA  will  first  provide  the  analyst  with  a  menu  of 
Mission  Areas  into  which  the  system  being  evaluated  will  fit. 

The  following  is  a  sample  list  of  Mission  Areas  taken  from  a 
taxonomy  developed  by  Kaplan  and  Crooks  (1980): 

•  Air  Defense  Weapons 

•  Armored  Vehicles 

•  Aviation  Systems 
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•  Battlefield  Communication  Systems 

•  C2  and  C2I  Systems 

•  Combat  and  Technical  Support  Equipment 

•  Electronic  Warfare  and  Surveillance  Systems 

•  Ground  Transportation  Systems 

•  Infantry  Weapons 

•  Ordinance  Systems 

•  Target  Acquisition  and  Designator  Systems 

When  the  analyst  selects  a  Mission  Area,  he  or  she  will  be 
presented  with  a  list  of  major  system  categories  that  fall  under 
that  Mission  Area.  For  example,  if  an  analyst  selects  "Armored 
Vehicles"  as  the  Mission  Area,  a  menu  similar  to  the  one  shown  in 
Figure  58  will  be  displayed.  From  this  screen,  the  analyst  can 
select  a  category  for  the  system  under  evaluation. 

When  the  analyst  has  selected  a  category,  he  or  she  will 
have  access  to  component  maintenance  parameter  data  for  one  or 
more  fielded  systems  within  that  category  that  reside  in  the 
Library.  These  data  can  be  used  as  a  baseline  or  starting  point 
for  the  government  estimates  of  maintenance  requirements.  In  the 
example  used  above,  if  the  analyst  selects  "main  battle  tanks"  as 
the  major  system  category,  a  menu  of  fielded  main  battle  tanks 
for  which  component  maintenance  parameters  are  contained  in  the 
Library  will  display  on  the  screen.  Figure  59  is  an  example  of 
what  the  menu  might  look  like.  This  example,  and  all  examples  of 
user  interfaces  are  intended  to  convey  the  context  of  the 
information  presented  to  the  analyst.  The  final  formats  and 
designs  of  all  user  interfaces  will  be  based  on  the  final 
software  design,  human  factors  analysis,  and  input  from  potential 
users  of  this  aid. 

The  components  for  each  major  system  in  each  library  are 
grouped  according  to  the  functional  systems  within  the  overall 
system  (e.g.,  hydraulic,  avionics,  armament,  etc.)  When  the 
analyst  selects  a  major  system,  a  menu  of  the  functional  systems 
within  that  major  system  will  display  on  the  screen.  Figure  60 
illustrates  a  sample  menu  of  functional  systems. 

The  process  of  selecting  a  specific  major  or  functional 
system  from  the  Library  of  Component  Maintenance  Parameters  will 
involve  the  analyst  selecting  from  a  series  of  menus  described 
above.  These  menus  will  allow  him  to  converge  on  specific 
subsets  of  component  parameters  of  interest  to  him. 
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Select  Major  System  Category  Menu 


Select  Major  System  Category 
Mission  Area:  Armored  Vehicles 

1.  Main  Battle  Tanks 

2.  Armored  Reconnaissance  Vehicles  and  Light  Tanks 

3.  Infantry  and  Calvary  Fighting  Vehicles 

4.  Armored  Personnel  Carriers 


Enter  a  number  and  then  press  <RETURN>: 


Figure  58.  Major  System  Category  Menu 


Select  Major  System  Menu 


Select  Major  System 

Mission  Area:  Armored  Vehicles 
Category:  Main  Battle  Tanks 

1.  M60 

2.  Ml 

3. 

4. 

Enter  a  number  and  then  press  <RETURN>_ 


Figure  59.  Major  System  Menu 
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Select  Functional  System  Menu 


Select  Functional  System 

Mission  Area:  Armored  Vehicles 
Major  System:  M60  Tank 

1.  Hydraulic  system 

2 .  Armament 

3. 

4. 

5 .  Engine 


Enter  a  number  and  then  press  <RETURN>_ 

quit  =  go  to  previous  screen  <esc>  =  return  to  working  file 


Figure  60.  Functional  System  Menu 


There  are  good  reasons  to  organize  the  components  by 
functional  system.  The  first  is  that  it  allows  the  analyst  to 
work  with  a  manageable  portion  of  an  overall  system.  It  also  may 
be  that  the  design  being  evaluated  is  only  a  modification  of  an 
existing  system.  In  this  case,  there  may  be  a  number  of 
functional  systems  that  will  not  be  modified. 

Another  major  benefit  to  accessing  component  maintenance 
parameter  data  from  the  library  by  functional  system  rather  than 
by  overall  system  is  that  it  makes  it  possible  for  the  analyst  to 
build  a  data  file  of  maintenance  parameters  for  the  design  being 
evaluated  from  functional  systems  of  more  than  one  major  system. 
For  example,  a  proposed  new  helicopter  may  include  an  avionics 
system  similar  to  that  of  an  Apache  and  a  hydraulic  system  more 
like  that  of  a  Cobra. 

working  with  component  data  by  functional  system  also 
encourages  a  top  down  approach  to  the  estimation  of  component 
maintenance  parameters . 
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When  the  analyst  has  selected  a  subset  of  components  within 
the  overall  major  system,  he  or  she  will  be  able  to  scroll 
through  a  list  of  components  within  that  functional  system, 
similar  to  the  illustration  in  Figure  61.  For  each  component  in 
the  list,  there  will  be  a  description  that  will  include: 

•  the  function  of  the  component. 

•  its  approximate  location  in  the  system. 

•  other  identifying  information  such  as  an  indication  of 
size  or  a  MIL  SPEC  number  . 

The  component  description  will  help  the  analyst  determine  if 
the  component  is  comparable  to  the  one  in  the  system  design. 

When  the  analyst  locates  a  component  that  is  appropriate  to  use 
as  a  baseline  estimate,  he  or  she  can  display  the  -^intenance 
parameters  for  that  component  and  copy  them  directly  into  the 
Component  Maintenance  Parameter  Template. 

Table  4  contains  a  list  of  the  component  maintenance 
parameters  included  for  each  major  system  component  in  the 
baseline  library.  These  parameters  are  required  as  input  for  the 
simulation  model. 

When  the  analyst  decides  to  exit  from  the  list  of  components 
in  the  current  functional  system,  he  or  she  is  presented  with  a 
display  of  the  functional  systems  currently  saved  in  the  working 
file  similar  to  the  one  shown  in  Figure  62.  From  this  screen,  he 
or  she  will  be  able  to  copy  the  component  maintenance  parameters 
of  another  functional  system  from  the  Library.  The  analyst 
continues  this  process  of  copying  component  maintenance 
parameters  from  the  functional  systems  of  similar  major  systems 
in  the  Library  until  all  of  the  functional  systems  included  in 
the  design  that  is  being  evaluated  have  been  covered. 

Identifying  Baseline  Estimates  from  Other  Available  Sources 

When  there  is  no  major  system  or  functional  system  in  the 
baseline  library  that  is  suitable  for  use  as  baseline  estimates 
of  component  maintenance  parameters  for  the  design  that  is  being 
evaluated,  the  analyst  will  have  the  option  to  obtain  similar 
system  component  data  from  other  available  sources  and  enter  it 
into  blank  Component  Maintenance  Parameter  Templates.  When  the 
analyst  exits  from  the  SELECT  MAJOR  SYSTEM  menu  (Figure  59) 
without  selecting  a  listed  option,  the  screen  showing  the 
functional  systems  currently  in  the  working  file  is  displayed  on 
the  screen.  To  obtain  a  blank  template  for  entry  of  components 
and  parameters  from  similar  systems  not  contained  in  the  Library, 
the  analyst  selects  to  "add”  a  functional  system  to  the  working 
file.  After  entering  the  add  command,  a  blank  Component 
Maintenance  Parameter  Template  is  displayed  on  the  screen. 
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COMPONENT  DESCRIPTIONS 


Major  System:  M60  Tank 

Functional  System:  Command  and  control  display 
Component  name:  Description: 


CRT  Monochrome  video  display,  8  inch 

diagonal  screen  with  brightness  and 
contrast  controls.  Located  in  Tank 
Commander  control  station. 


video  circuit  board  9  inch  X  3.5  inch  printed  circuit 

board  with  memory  modules  and  video 
EPROM  display  chip.  Located  in  the 
CPU  cabinet. 


Press  <F2>  to  see  the  maintenance  parameters  for  the  current 
component . 

Press  the  up  or  down  arrow  keys  to  highlight  additional  or 
previous  components. 


Figure  61.  List  of  Components  in  the  Baseline  Library 


i 
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Working  File  Listing  of  Functional  Systems 


Functional  Systems 

1.  Armament  System 

2 .  Engine 

3 .  Communications 

4. 

5. 


Command  (a,  m,  d,  c,  s):_ 

add  =  add  functional  system  components  using  a  blank  template 
modify  «  display  existing  functional  system  template 
delete  *  delete  a  template 

copy  *  copy  a  template  from  the  Library  or  another  working  file 
save  =  save  all  changes  made  to  this  working  file 


Figure  62.  Listing  of  Functional  Systems 


The  analyst  will  begin  the  search  for  similar  system 
maintenance  requirements  by  investigating  the  currently  fielded 
equipment  that  the  proposed  design  is  going  to  replace.  If  the 
design  being  evaluated  is  a  modification  to  the  existing  system, 
The  analyst  may  be  able  to  identify  other  equipment  that  has 
undergone  the  same  or  similar  modifications. 

When  the  new  design  is  so  radically  different  from  its 
predecessor  that  it  can't  be  used  as  a  baseline  for  evaluation  of 
the  new  design,  the  analyst  can  examine  the  functional 
requirements  of  systems  contained  in  Army,  DoD,  and  NATO 
equipment  inventories  for  candidate  major  systems  or  functional 
systems  for  baseline  estimates.  The  analyst  may  also  elicit 
input  from  subject  matter  experts  in  the  proposed  mission  area  to 
identify  candidate  systems  to  be  used  for  identification  of 
baseline  estimates. 

When  a  list  of  candidate  systems  has  been  identified,  the 
analyst  will  obtain  the  system  design  and  functional 
specifications  for  each  potential  system.  The  baseline  estimates 
may  be  compiled  from  a  single  currently  deployed  system  that  is 
very  similar  to  the  proposed  system.  However,  it  is  more  likely 
that  the  baseline  estimates  will  be  a  composite  of  current 
systems  with  functional  systems  or  sub-systems  that  are  similar 
to  the  proposed  system. 

When  a  suitable  configuration  of  functional  systems,  sub¬ 
systems  and  components  has  been  identified  the  analyst  can  enter 
the  component  list  into  blank  functional  system  Templates. 

To  assist  the  analyst  in  obtaining  maintenance  data  on 
fielded  systems  not  in  the  Library,  we  will  develop  software  to 
allow  access  to  selected  military  data  bases  directly  from  the 
Component  Maintenance  Parameter  Template.  This  access  will  be 
accomplished  through  the  use  of  software  windows  in  much  the  same 
way  that  the  analyst  gains  access  to  the  Component  Maintenance 
Parameter  Library.  DRC  currently  maintains  a  direct  access  link 
to  the  Sample  Data  Collection  Data  Base. 

The  component  maintenance  parameters  for  existing  systems 
can  be  gathered  from  Sample  Data  Collection  (SDC)  data,  Technical 
Manuals  for  maintenance  activities,  and  subject  matter  experts. 
Figure  63  shows  a  Maintenance  Allocation  Chart  from  the  Technical 
Manual  for  M880  Series  Trucks,  From  this  chart,  the  analyst  can 
identify  the  maintenance  action  (function),  the  maintenance 
category,  and  the  average  time  to  perform  the  maintenance  action. 
Figure  64  is  an  example  of  the  kind  of  data  that  can  be  obtained 
from  the  SDC  data  base.  Similar  output  can  be  obtained  by 
maintenance  action  or  task,  maintenance  organization,  MOS,  skill 
level,  etc. 
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MAINTENANCE  ALLOCATION  CHART 

'  Table  B-l-  Maintenance  Allocation  Chart 


C  ■  Crvw/Operaior  0  •  Orgintuuoiul  F  •  Direct  Support  H  ■  Ctnenl  Support  D  -  Depot 


(I) 

(2) 

(3) 

(4) 

<J) 

Croup 

Maintenance 

Maintenance  category 

Tools  and 

number 

Component/assembly 

function 

C 

0 

F 

H 

D 

equipment 

01 

ENCINE 

0100 

Engine 

Inspect 

Test 

.4 

1.5 

Service 

1.0 

Adjust 

Replace 

Repair 

3.7 

6.0 

A 

Mount,  engine 

Inspect 

Replace 

.3 

1.5 

0101 

Cylinder  block 

Inspect 

Replace 

6.3 

6.3 

Repair 

A 

Plug,  expansion 

Inspect 

Replace 

. 

.1 

.6 

Cylinder  head 

Inspect 

4.2 

Replace 

3.9 

Repair 

5.7 

0102 

Crankshaft 

Inspect 

Replace 

2.9 

11.4 

* 

Seals,  main 

Inspect 

.2 

Replace 

6.0 

Pulley 

Inspect 

.2 

Replace 

1.0 

Balancer,  crankshaft 

Inspect 

.2 

(harmonic  balancer) 

Bearing,  crankshaft 

Replace 

Inspect 

I  4 

4  5 

Replace 

4.5 

0104 

Piston  and  pins 

Inspect 

12.0 

Replace 

13.3 

Rings 

Inspect 

12.0 

Replace 

12.0 

Rod.  connecting 

Inspect 

12.0 

Replace 

13.3 

Bearing,  connecting 

Inspect 

6.2 

Replace 

6.2 

0105 

Camshaft 

Inspect 

7.2 

Replace 

7.2 

Cover,  cylinder  head 

Inspect 

.2 

(valve  cover) 

Replace 

1.1 

A—  In  i*l*  c*t««Of  v,  no  ipocKic  timot  cm  •«i*oinh*a. 


R-2  Change  2 


Figur*  63.  Maintenance  Allocation  Chart 
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Figure  64.  Sample  Data  Collection  Data  Base  Output 
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Other  maintenance  documentation  such  as  the  maintenance  task 
analysis  can  be  used  to  determine  the  MOS  and  skill  level 
required  to  perform  the  maintenance  and  the  type  of  maintenance 
(planned  or  corrective) .  Maintenance  accuracy  for  diagnose  and 
troubleshoot  activities  can  be  generated  by  examining  False 
Removal  Rates  from  the  SDC  and  other  related  maintenance  data 
bases.  Information  on  whether  or  not  a  failure  of  a  specific 
component  is  likely  to  cause  the  mission  to  be  aborted  can  be 
estimated  from  examining:  1)  system  safety  data  bases  that 
identify  components  critical  to  system  and  human  safety,  2)  items 
marked  "RED  X",  and  3)  input  provided  by  subject  matter  experts 
and  analyst  judgement. 

The  standard  deviation  for  the  time  it  takes  to  perform  a 
maintenance  action  can  also  be  obtained  from  SDC  data.  For 
situations  when  data  for  calculating  standard  deviations  is  not 
available,  we  will  develop  some  strategies  and  heuristics  for 
estimating  standard  deviations  of  repair  times.  For  example,  we 
could  collect  data  from  available  logistic  support  centers  to 
determine  standard  deviations  for  some  number  of  maintenance 
activities  performed  in  different  maintenance  categories  for 
systems  used  in  different  mission  areas.  With  this  information, 
we  could  calculate  the  average  percentage  of  the  mean  repair  time 
for  all  of  the  maintenance  activities  studied.  This  "percentage 
of  the  mean"  could  then  be  used  as  the  default  standard 
deviation.  The  analyst  could  of  course  change  that  value  for  any 
particular  maintenance  action.  A  slightly  inaccurate  estimate  of 
the  standard  deviation  will  tend  to  be  washed  out  by  modeling 
maintenance  requirements  over  a  long  period  of  time  such  as  a 
year. 


Some  of  the  required  component  maintenance  parameters  will 
probably  need  to  be  converted  or  estimated  from  the  maintenance 
data.  For  example,  the  mean  operational  units  between  failure  of 
a  component  may  need  to  be  converted  to  another  metric. 

Output 

The  output  of  Step  2  is  a  set  of  data  files  of  system 
components  and  maintenance  parameters  copied  from  the  baseline 
library  of  component  parameters  for  a  comparable  system  or 
derived  from  maintenance  documentation  of  similar  fielded 
systems.  Each  file  in  the  set  contains  the  component  maintenance 
parameters  for  one  functional  system  within  the  overall  system. 
Each  file  will  be  accessed  from  the  menu  of  functional  systems 
shown  in  Figure  62. 

User  Interface  Issues 


The  user  interface  for  the  aid  to  identifying  baseline 
estimates  of  system  component  parameters  will  consist  generally 
of  menus  and  prompts  that  will  allow  the  analyst  to  obtain 
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of  menus  and  prompts  that  will  allow  the  analyst  to  obtain 
estimates  from  the  baseline  library  for  comparable  systems  and 
spreadsheet-like  templates  for  entering  and  modifying  component 
parameters.  Context  specific  help  in  the  form  of  definitions, 
guidelines,  and  decision  aids  will  be  embedded  in  the  software  so 
that  the  analyst  can  access  additional  information  for  any  menu 
item,  prompt  or  cell  entry  at  all  times. 

The  actual  design  of  menus,  selection  procedures,  and 
keyboard  routines  will  be  developed  based  on  input  from  intended 
users,  human  factors  analysis,  and  the  final  software  design. 

4.2.3  Step  3  Identify  discrepancies  between  the  government 

baseline  estimates  and  the  contractor's  estimates 
of  compc.ient  maintenance  parameters. 


Input 


Internal  -  The  functional  system  data  files  containing  both 
baseline  data  and  available  contractor  estimates  of  component 
maintenance  parameters  for  the  proposed  system  design  that  were 
completed  in  Step  2 . 

External  -  Analyst  judgment  on  the  amount  of  tolerance  he 
will  accept  for  deviations  between  the  baseline  data  and  the 
contractor's  estimates. 

Process 

The  performance  of  this  step  is  dependent  on  the 
availability  of  the  contractor's  design  estimates  of  at  least 
some  of  the  component  maintenance  parameters.  When  the 
contractor's  design  doesn't  contain  any  estimates  of  component 
maintenance  parameters,  the  analyst  will  use  the  baseline 
estimates  as  the  only  input  to  the  simulation  model.  When  this 
is  the  case,  the  analyst  can  skip  this  step. 

The  purpose  of  this  step  is  to  compare  the  government 
baseline  and  contractor  estimates  for  each  component  maintenance 
parameter  value  to  identify  and  produce  an  MMAA  generated  list  of 
discrepancies  between  the  two  estimates.  Whenever  possible,  we 
want  to  take  advantage  of  the  fact  that  many  of  the  components  in 
a  new  system  are  not  entirely  new  designs.  By  comparing  the 
contractor  estimated  maintenance  requirements  of  new  system 
components  to  baseline  data,  the  analyst  can  identify  those 
components  that  are  of  the  highest  risk  of  inaccurate  estimates 
or  those  for  which  insufficient  data  exists. 

When  the  Component  Maintenance  Parameter  Files  contain  all 
of  the  baseline  and  contractor  estimates,  the  analyst  can  have 
the  MMAA  sort  through  each  pair  of  estimates  for  each  component 
and  parameter  to  identify  discrepancies.  However,  before  this  is 
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done,  the  analyst  needs  to  specify  reasonable  tolerances  for  the 
comparison  of  values.  It  is  highly  unlikely  that  an  exact  match 
will  be  found  for  any  of  the  component  parameters  that  contain 
numeric  values  such  as  time  or  accuracy  even  when  the  contractor 
and  the  baseline  estimates  are  nearly  the  same.  In  other  words, 
the  analyst  may  choose  to  "accept”  (as  a  non-difference)  any  time 
to  repair  value  that  is  within  10  percent  of  the  baseline 
estimate. 

The  MMAA  will  allow  the  analyst  to  specify  percentage 
tolerances  for  numeric  values.  Component  Maintenance  Parameters 
that  consist  of  textual  or  coded  data  such  as  the 
MOS,  skill  level  and  category  will  not  accept  tolerances. 

When  the  analyst  is  ready  to  have  the  MMAA  sort  one  or  more 
of  the  Component  Maintenance  Parameter  Templates  for 
discrepancies  he  will  return  to  the  IDENTIFY  COMPONENT 
MAINTENANCE  PARAMETERS  menu  and  select  the  "Sort  Matrices"  option 
shown  in  Figure  65.  The  analyst  will  have  the  option  to  sort  and 
identify  discrepancies  for  a  single  functional  system  template  or 
to  sort  all  of  the  templates  currently  developed.  The  MMAA  will 
then  sort  the  two  entries  for  each  component  parameter  for 
differences.  Contractor  estimates  that  are  missing  will  be 
ignored  in  the  sort. 

When  a  sort  has  taken  place,  all  discrepancies  between  each 
pair  of  Component  Maintenance  Parameter  estimates  are  stored  in  a 
data  file  by  functional  system. 

The  IDENTIFY  COMPONENT  MAINTENANCE  PARAMETERS  menu  also  has 
an  option  to  display  on  the  screen  or  print  a  list  of  all 
identified  discrepancies  for  a  single  functional  system  or  for 
all  of  the  functional  system  files  that  have  currently  been 
sorted . 

Output 

The  results  of  the  sort  operation  will  store  a  list  of 
differences  or  discrepancies  between  the  contractor's  estimate  of 
a  component  parameter  and  the  baseline  estimate  by  functional 
system.  Discrepancies  that  fall  within  the  tolerance  specified 
by  the  analyst  will  not  appear  in  the  discrepancy  list. 

Functional  system  files  not  included  in  a  sort  will  not  be 
affected  by  a  sort  operation. 

User  Interface  Issues 

-i  '-■■■  -  1  ~ 

Users  will  specify  tolerances  for  the  identification  of 
discrepancies  between  Component  Maintenance  Parameter  estimates 
by  selecting  options  from  menus,  responding  to  prompts  that 
appear  on  the  screen  and  entering  information  with  an  input 
device  such  as  a  keyboard  or  a  mouse.  For  example,  Figure  65  is 
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an  illustration  of  what  an  IDENTIFY  COMPONENT  MAINTENANCE 
PARAMETERS  menu  might  look  like. 


Identify  Component  Maintenance  Parameters  Menu 


Identify  Component  Maintenance  Parameters 

Develop  Component  Maintenance  Parameters 
Specify  Tolerances  for  Comparisons 
Sort  Matrices 
Report  Discrepancies 


Enter  a  number  and  then  press  <RETURN> 


Figure  65.  Identify  Component  Maintenance  Parameters  Menu 


From  this  menu,  to  specify  tolerances  for  the  sort 
operation,  the  analyst  would  select  option  2  (Specify  Tolerances 
for  Comparisons) .  After  making  this  selection,  he  will  be  given 
the  option  to  specify  tolerances  for  all  of  the  functional 
systems  currently  defined,  a  single  functional  system,  or  a 
single  component.  He  will  also  be  given  a  choice  to  enter  a 
percentage  tolerance  by  Component  Maintenance  Parameter  or  for 
all  parameters. 

When  the  analyst  selects  option  3  (Sort  Templates)  a  prompt 
will  display  on  the  screen  asking  the  analyst  to  enter  the  name 
of  the  functional  system  on  which  to  sort.  At  this  point  the 
analyst  could  either  enter  the  name  of  a  functional  system  or  the 
word  "ALL" .  When  he  enters  the  word  "ALL" ,  all  of  the  functional 
system  files  that  have  been  defined  will  be  sorted. 


4.2.4  Step  4  Resolve  the  discrepancies  between  the  government 

baseline  estimates  and  the  contractor's  design 
estimates  of  Component  Maintenance  Parameters. 


Input 


Internal  -  The  Component  Maintenance  Parameter  discrepancy 
data  file  created  in  step  3. 

External  -  The  external  inputs  for  resolving  Component 
Maintenance  Parameter  discrepancies  are  the  following: 

•  Maintenance  Subject  Matter  Experts 

•  System  design  documents  including  the  maintenance  task 
analysis 

•  System  design  engineers 

•  Analyst  judgment 

Process 


When  the  MMAA  has  identified  and  stored  discrepancies 
between  contractor  and  government  estimates  of  Component 
Maintenance  Parameters,  the  analyst  can  select  the  "Generate 
Discrepancy  Reports"  option  from  the  IDENTIFY  COMPONENT 
MAINTENANCE  PARAMETERS  menu  to  display  or  print  out  reports  of 
all  discrepancies  by  functional  system  and  component.  The 
analyst  can  use  these  reports  as  a  guide  to  resolving  the 
discrepancies . 
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Before  the  analyst  can  exercise  the  computer  simulation  to 
obtain  maintenance  manhour  requirements,  all  of  the  discrepancies 
that  were  identified  by  the  software  must  be  resolved.  The 
following  paragraphs  describe  some  of  the  methods  an  analyst  may 
use  to  resolve  each  kind  of  discrepancy. 

Components  for  which  there  are  no  baseline  data  -  Any  new 
system  is  likely  to  contain  new  hardware  or  software  components 
for  which  there  are  no  existing  baseline  maintenance  data.  This 
can  occur  when  the  proposed  new  system  has  automated  a  function 
that  was  performed  by  human  operators  in  previous  systems.  New 
system  components  are  added  to  the  list  of  baseline  components  by 
the  analyst.  However,  the  analyst  must  still  decide  whether  or 
not  to  use  the  contractor's  estimates  of  the  maintenance 
parameters  or  modify  them  based  on  his  her  judgement  and 
experience.  The  analyst  may  seek  to  obtain  data  from  other 
systems  that  utilize  a  similar  component,  get  input  from  subject 
matter  experts,  or  elicit  further  information  and  justification 
from  the  contractor.  When  data  from  similar  systems  is 
unavailable,  maintenance  estimates  can  be  obtained  by  conducting 
motion-time  estimation  techniques  or  Human  Operator  Simulator 
(HOS)  modeling.  The  mechanisms  for  making  these  estimates  will 
be  embedded  in  the  MMAA  as  they  were  in  the  WAA  (as  discussed  in 
Section  4.1.4) . 

Significant  differences  between  the  contractor's  estimates 
and  the  baseline  data  -  The  primary  goal  of  this  part  of  the 
evaluation  is  to  obtain  the  best  estimate  of  maintenance 
requirero  nts  for  each  hardware  or  software  system  component  for 
the  system  design  being  evaluated.  However,  it  probably  isn't 
necessary  for  the  analyst  to  spend  time  analyzing  the  maintenance 
requirements  for  components  for  which  the  government  and 
contractor's  estimates  agree.  Unless,  of  course,  the  analyst  has 
some  knowledge  or  information  that  makes  him  suspect  of  the 
baseline  estimate.  Changing  the  parameters  will  always  be  an 
option  available  to  the  analyst. 

«• 

In  most  cases,  the  analyst  will  want  to  identify  differences 
in  the  contractor  and  baseline  estimates  and  resolve  those 
differences.  As  stated  earlier,  the  analyst  will  be  able  to 
specify  tolerances  for  each  of  the  maintenance  parameters  so  that 
exact  matches  for  data  that  are  very  close  in  value  are  not 
required. 

Sources  of  input  for  resolution  of  discrepancies  may  be 
SMEs,  similar  system  components  used  in  other  systems,  HOS 
modeling,  MTM  techniques,  or  from  details  contained  in  the  system 
design.  For  example,  a  difference  in  the  maintenance  category 
or  MOS  and  skill  level  required  may  be  due  to  new  diagnostic  or 
test  features  built  into  the  component  in  the  new  design.  In 
this  case  it  may  be  necessary  to  obtain  input  from  Army  design 
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engineers  or  engineers  involved  in  the  design  of  the  new 
component.  If  resolution  cannot  be  reached  through  these 
sources,  the  value  can  and  should  be  assessed  through  the  formal 
test  and  evaluation  process  which  will  take  place  later  in  the 
MAP. 


Required  component  parameters  missing  from  the  new  design  - 
The  contractor's  design  may  contain  some  but  not  all  of  the  data 
required  for  the  calculation  of  maintenance  manhours  via  the 
simulation  model.  The  design  documents  may  also  have  reported 
the  required  parameter  but  in  a  different  metric  than  is 
available  in  the  baseline  data.  The  analyst  can  either  convert 
the  value  to  the  proper  metric,  if  possible,  elicit  a  new  value 
from  the  contractor,  obtain  input  from  other  available  sources, 
or  decide  to  use  the  baseline  estimate. 

Whatever  process  the  analyst  uses  to  resolve  the  identified 
discrepancies,  the  Component  Maintenance  Parameter  Templates  must 
be  modified  to  show  the  best  estimate  of  maintenance  requirements 
per  component  in  the  top  portion  of  each  cell.  In  other  words, 
each  cell  will  always  contain  two  parameters:  the  top  portion 
showing  the  analyst's  best  estimate  and  the  bottom  portion 
showing  the  contractor's  estimate. 

The  simulation  model  that  will  determine  the  total 
maintenance  requirements  for  the  overall  system  can  be  executed 
with  either  set  of  component  parameter  estimates  for  comparative 
purposes  if  the  analyst  so  desires. 

Output 

The  outputs  of  this  step  are  the  Component  Maintenance 
Parameter  Files  generated  from  the  Component  Maintenance 
Parameter  Templates  that  contains  two  sets  of  estimates  for  the 
maintenance  parameters  of  each  component  in  the  system.  One  is  a 
set  of  the  best  available  estimates  that  could  be  obtained  by  the 
analyst.  The  other  is  the  set  of  the  contractor's  estimates. 

Either  set  of  estimates  could  be  used  as  input  for  the 
simulation  model  of  maintenance  requirements. 

User  Interface  Issues 

The  process  for  generating  discrepancy  reports  is  one  of 
luenu  selection  and  response  to  prompts  that  display  on  the 
screen.  The  spreadsheet-like  Component  Maintenance  Parameter 
Templates  will  be  used  to  change  the  baseline  estimates  to  the 
best  available  estimates. 
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Step  5  Identify  and  develop  parameters  for  each  mission 
scenario  to  be  analyzed  in  terms  of  maintenance 
manhour  requirements,  system  availability,  and 
system  reliability. 


Input 


Internal  -  Mission  requirements  obtained  from  the  System 
Performance  Requirements  Estimation  Aid  (SPREA)  in  Product  1. 

External  -  Data  on  mission  requirements  will  be  obtained 
from  the  Operation  Mode  Summary  and  Mission  Profile,  MAA  and  MADP 
results,  LSA,  and  the  Army's  Sample  Data  Collection  System  (see 
Figure  66) . 

Process 


When  the  analyst  has  modified  the  baseline  estimates  of 
component  parameters  to  reflect  the  best  available  estimates  of 
component  maintenance  requirements,  he  or  she  will  access  the 
maintenance  simulation  model  to  define  a  mission  scenario  for  the 
computer  simulation.  The  analyst  will  not  need  to  be  concerned 
with  building  the  model  itself  or  with  specifying  any  of  the 
logic  or  algorithms  needed  to  simulate  the  maintenance 
requirements.  The  analyst  will  need  to  enter  the  following 
information  to  describe  the  mission  being  simulated: 

1.  Simulation  period  -  This  is  the  number  of  days  of 
maintenance  activities  to  be  simulated.  Normally  this 
will  be  one  year. 

2 .  Number  of  missions  per  dav  -  One  of  the  calculations 
that  is  used  to  determine  the  total  operational  units, 
standby  time,  and  availability  of  the  system  for  the 
time  period  specified  for  the  simulation. 

3.  Mission  length  -  In  order  to  simulate  the  amount  of 
operational  time  for  each  of  the  system  components,  a 
mean  time  and  standard  deviation  estimate  of  mission 
length  will  be  derived  from  the  external  input  data 
sources  described  in  section  4. 2. 5.1. 

4.  Mission  frequency  -  Mean  and  standard  deviation  values 
(assuming  a  normal  distribution)  are  entered  to 
represent  the  amount  of  time  between  missions.  This 
information  is  used  by  the  simulation  model  to 
calculate  the  cumulative  operational  units  over  time. 
The  mission  frequency  values  are  also  used  to  establish 
"windows”  within  which  all  maintenance  must  occur  to 
ensure  the  availability  of  the  system  for  any 
particular  mission.  For  example,  if  a  mission  in  the 
simulation  is  scheduled  to  begin  based  on  the  mission 
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Figure  66.  Sample  Data  Collection  Output  of  Mission  Parameters 
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frequency  requirements  and  the  required  maintenance  for 
the  system  has  not  been  completed,  the  system  will  not 
be  available  for  that  mission.  The  mission  frequency, 
mission  length,  and  number  of  missions  per  day  will 
determine  the  total  number  of  possible  missions. 

Therefore,  the  probability  of  a  system  being  available 
can  be  calculated  using  the  following  equation: 

prob  =  1  -  (missions  missed/missions  possible) 

5.  Component  operational  units  per  mission  -  The 
operational  units  per  mission  is  a  value  that 
represents  the  amount  of  use  a  system  component 
receives  during  a  mission.  The  metric  used  for  this 
value  will  vary  with  each  system  component  and  will 
correspond  to  the  metric  that  is  used  in  the  estimate 
of  mean  operational  unit  between  failure  (e.g.,  rounds 
fired,  miles  driven,  landings,  or  operational  time) . 

The  operational  units  per  mission  value  will  be  input 
as  a  numeric  constant  that  represents  either  mission 
averages  such  as  rounds  fired  or  the  percentage  of  time 
that  the  component  is  in  use  during  a  mission,  on 
average.  Because  of  the  potential  variety  of  missions 
that  may  be  required  of  a  single  system,  the 
operational  units  per  mission  will  not  be  included  in 
the  baseline  Library.  For  example,  the  new  LHX 
helicopter  currently  in  the  MAP  will  be  designed  to 
perform  both  attack  and  reconnaissance  missions.  The 
usage  of  different  equipment  such  as  rocket  launchers 
vs.  radar  components  will  be  different  for  each  mission 
scenario.  These  estimates  will  need  to  be  input  by  the 
analyst  at  the  time  the  other  mission  scenario 
information  is  defined. 

Sources  of  information  for  the  operational  units  per 
mission  are:  combat  models,  subject  matter  experts,  and 
system  engineers. 

Figure  67  is  an  illustration  of  what  the  DEVELOP  MISSION 
SCENARIO  menu  might  look  like. 

When  the  analyst  selects  the  "Component  Operational  Units 
per  Mission"  option  from  the  mission  scenario  menu,  a  second  menu 
will  display  a  list  of  the  functional  systems  within  the  overall 
system  currently  being  worked  on.  From  this  menu,  the 
analyst  can  select  a  subset  of  components  that  represent  a 
functional  system  for  which  to  enter  the  operational  units  per 
mission.  When  a  functional  system  has  beer,  selected,  a  matrix 
template  similar  to  the  one  shown  in  Figure  54  will  be  displayed 
on  the  screen.  The  left  column  of  the  matrix  will  contain  the 
list  of  components  that  were  listed  in  the  Component 
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DEVELOP  MISSION  SCENARIO 


1.  Mission  name:  Destroy  Enemy  Vehicles 

2.  Simulation  time  span  (days):  365 

3.  Average  number  of  missions  per  day:  4 

4.  Mission  duration  mean  time  (hours):  2 

5.  Mission  duration  standard  deviation:  .5 

6.  Time  between  missions  (mean):  2 

7.  Time  between  missions  (std  dev):  .1 

8.  Component  operational  units  per  mission 

Enter  a  number  and  then  press:  <RETURN>_ 


Figure  67.  Develop  Mission  Scenario  Menu 
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Figure  68.  Operational  Units  Per  Mission  Template 
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Maintenance  Parameters  Template  for  that  functional  system.  The 
analyst  can  move  around  in  the  matrix  of  cells  using  cursor 
control  keys  to  add,  modify,  delete,  and  copy  operational  units 
per  mission  values  in  much  the  same  way  one  would  enter  data  into 
an  electronic  spreadsheet.  This  process  is  repeated  for  all  of 
the  functional  systems  within  the  overall  system. 

When  all  of  the  mission  scenario  data  has  been  defined,  the 
analyst  can  exercise  the  maintenance  computer  simulation  model  to 
obtain  estimates  of  the  total  maintenance  manhour  requirements 
for  the  currently  defined  mission  scenario.  The  aid  will  also 
provide  the  analyst  with  a  mechanism  for  saving,  retrieving,  and 
copying  mission  scenarios  for  a  particular  system.  This  will 
allow  an  analyst  to  create  new  mission  scenarios  without  starting 
from  scratch  by  modifying  a  scenario  that  is  close  to  the  one  the 
analyst  wants  to  simulate. 

Output 

The  output  of  this  step  is  a  data  file  of  Mission  Scenario 
Parameters  for  each  type  of  mission  required  of  the  system  design 
that  is  being  evaluated.  Each  mission  scenario  data  file  will  be 
used  as  input  for  an  execution  of  the  Maintenance  Requirements 
Simulation  model. 

User  Interface  Issues 


The  process  of  defining  mission  scenario  parameters  will 
consist  of  selecting  menus  and  responding  to  prompts  to  access 
the  DEVELOP  MISSION  SCENARIO  menu.  When  the  analyst  selects  to 
enter  the  operational  units  per  mission  for  system  components,  he 
will  be  presented  with  a  spreadsheet-like  Mission  Scenario 
Template  similar  to  the  Component  Maintenance  Parameters 
Template. 

Each  mission  scenario  can  be  saved,  recalled,  copied,  and 
modified  so  that  the  analyst  can  easily  develop  a  number  of 
similar  scenarios  for  different  missions  required  of  the  system 
being  evaluated. 

4.2.6  Step  6  Exercise  the  computer  simulation  to  calculate  the 

maintenance  manhour  recruirements .  system 
availability,  and  system  reliability  for  each 
mission  scenario. 


Inputs 

Internal  -  The  Maintenance  Component  Parameter  file 
developed  by  the  analyst  in  Steps  1-4  and  the  mission  scenario 
file(s)  developed  in  Step  5. 

External  -  None 
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Process 


The  process  discussed  here  is  a  description  of  the 
activities  performed  by  the  analyst  to  exercise  the  Maintenance 
Requirements  Simulation  Model  that  is  embedded  in  the  MMAA.  A 
detailed  discussion  of  this  network  model  can  be  found  in  section 
4.3.4. 


When  all  of  the  Component  Maintenance  Parameters  and  Mission 
Scenario  Parameters  have  been  defined,  the  execution  of  the 
Maintenance  Requirements  Simulation  Model  is  simply  a  matter  of 
selecting  the  "Execute  Maintenance  Simulation  Model"  option  from 
the  DEVELOP  MAINTENANCE  REQUIREMENTS  menu.  The  system  will 
prompt  the  analyst  to  enter  the  name  of  the  system  to  be  modeled 
and  indicate  whether  the  "best  available"  Maintenance  Component 
Parameter  estimates  or  the  contractors  estimates  are  to  be  used. 

If  any  of  the  required  input  from  the  Component  Maintenance 
Parameter  or  Mission  Scenario  data  files  is  missing,  incomplete, 
or  in  error,  the  software  will  issue  an  error  message  and,  if 
possible,  continue  execution.  If  a  fatal  error  is  encountered, 
the  execution  will  terminate.  Each  error  message  that  is  issued 
during  the  execution  will  be  stored  in  a  data  file  that  can  be 
viewed  or  printed  out  via  the  Reports  Generator  that  will  be 
discussed  in  Step  7 . 

Output 

The  output  of  the  simulation  model  will  be  a  data  file  that 
will  serve  as  a  relational  data  base  of  maintenance  requirements 
for  the  proposed  system.  The  data  base  will  contain: 

•  Maintenance  manhour  requirements  by: 

component 

-  functional  system 

-  MOS  and  skill  level 
maintenance  category 

maintenance  type  (planned  or  corrective) 
maintenance  action 

•  System  availability 

•  System  reliability 

•  Functional  system  reliability 
User  Interface  Issues 


The  only  user  interface  involved  with  executing  the 
Maintenance  Requirements  Simulation  is  menu  selection  and 
response  to  system  prompts. 
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4.2.7  Step  7  Evaluate  the  results  of  the  computer  simulation  in 

terms  of  the  maintenance  jobs  that  are  required, 
the  tasks  that  make  up  each  job,  the  number  of 
maintenance  hours  required  per  nob,  system 
performance  requirements  and  manpower  constraints. 


Inputs 

Internal  -  The  data  file  containing  the  execution  results  of 
the  Maintenance  Requirements  Simulation  generated  in  Step  6  of 
the  Maintenance  Manhour  Analysis  Aid. 

External  -  The  results  of  the  Manpower  Constraints 
Estimation  Aid  (MCEA)  that  is  an  output  of  Product  2  and  the 
results  of  the  System  Performance  Requirements  Estimation  Aid 
that  is  an  output  of  Product  1. 

Process 


The  execution  results  of  the  Maintenance  Requirements 
Simulation  are  stored  in  a  data  file  that  will  serve  as  a 
relational  data  base  of  maintenance  requirements  information.  A 
Maintenance  Reports  Generator  will  be  developed  to  allow  the 
analyst  to  obtain  information  from  the  data  base  file. 

The  Maintenance  Reports  Generator  will  produce  two  reports 
automatically  that  the  analyst  will  use  to  determine  the  overall 
maintenance  requirements  for  the  system  design.  The  first  is  a 
Maintenance  Manhour  Summary  Report.  This  report  is  a  table  of 
information  that  lists  each  maintenance  job  (MOS,  Skill  level  and 
Category)  that  is  required  by  the  system  design.  In  addition, 
the  summary  report  will  show  the  maintenance  tasks  by  component 
and  maintenance  action,  the  number  of  hours  spent  on  each  task, 
and  the  total  number  of  maintenance  manhours  for  all  tasks  within 
a  maintenance  job  designation. 

The  second  report  that  is  produced  automatically  is  the 
Maintenance  Headcount  Report.  This  report  will  complement  the 
Maintenance  Manhour  Summary  Report  by  showing  the  actual  number 
of  people  required  for  each  maintenance  job  and  the  percentage  of 
time  that  number  of  people  were  needed  to  maintain  system 
availability.  Included  with  this  report  will  be  a  set  of 
histograms  that  illustrate  the  headcount  percentages  by 
maintenance  job.  The  analyst  will  need  both  the  Maintenance 
Manhour  Summary  Report  and  the  Maintenance  Headcount  Reports  to 
accurately  evaluate  the  maintenance  requirements  for  the  proposed 
system  design. 
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The  Maintenance  Reports  Generator  will  also  allow  the 
analyst  to  ask  for  any  information  in  the  data  base  cross- 
referenced  with  any  other  data.  Following  is  a  list  of  some  of 
the  ways  that  the  analyst  can  get  reports  of  the  data: 

•  Total  system  maintenance  manhour  requirements 

•  Maintenance  manhours  by  MOS  and  skill  level 

•  Maintenance  manhours  by  MOS  and  skill  and  maintenance 
level 

•  Maintenance  manhours  by  component 

•  Maintenance  manhours  by  functional  system  (e.g. 

avionics  system,  armament,  etc.) 

•  Functional  system  reliability 

•  System  availability 


The  analyst  can  use  the  Maintenance  Reports  Generator  to 
display  information  informally  on  the  screen  of  his  work  station 
for  informational  purposes  or  he  can  define  the  format  of  more 
formal  reports  of  information  that  is  contained  in  the  data  base. 
The  Maintenance  Reports  Generator  will  also  allow  the  analysis  to 
produce  graphic  representations  of  the  maintenance  requirements 
data  such  as  a  frequency  distribution  of  failures  for  a 
particular  component  or  a  line  graph  of  the  total  maintenance 
manhour  requirements  over  time. 

The  analyst  will  compare  the  output  that  is  obtained  from 
each  execution  of  the  model  to  the  AAMH  constraints  determined 
from  the  Manpower  Constraints  Estimation  Aid  (MCEA)  and  to  the 
availability  and  reliability  requirements  obtained  from  the 
System  Performance  Requirements  Aid  (SPREA) . 

Output 

The  output  of  this  step  is  the  identification  of  potential 
design  deficiencies  in  terms  of  1)  the  estimated  manpower 
required  to  maintain  the  system  as  compared  to  the  manpower 
constraints  and  2)  the  estimated  availability  and  reliability  of 
the  system  as  related  to  maintenance  requirements  compared  to  the 
system  performance  requirements  determined  in  the  Product  1  of 
the  (MPT)2  process. 

Another  output  of  this  Step  7  is  a  set  of  maintenance 
requirements  reports  that  will  be  used  as  input  for  the  Trade- 
Off-Analysis  process  that  will  be  aided  by  Product  6  of  the 
(MPT)2  effort. 
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User  Interface  Issues 


The  Maintenance  Reports  Generator  will  be  a  menu  and  prompt 
driven  software  component  that  can  be  accessed  from  the  main  menu 
of  the  Maintenance  Manhour  Analysis  Aid.  It  will  include  a 
logical  command  structure  that  will  allow  the  analyst  to  cross- 
reference  stored  data  such  as  maintenance  manhours  by  component 
and  MOS,  skill  level  and  category. 

The  Maintenance  Reports  Generator  will  also  provide  the 
analyst  with  a  menu  and  prompt  driven  interface  to  specify 
graphical  and  statistical  analysis  of  the  results  of  the 
Maintenance  Requirements  Simulation. 


4.2.8  Step  8  Investigate  potential  solutions  to  maintenance 

deficiencies  bv  modifying  Component  Maintenance 
Parameters  and  re-running  the  model . 


Inputs 

Internal  -  Maintenance  workload  deficiencies  in  the  system 
design  that  were  identified  in  Step  7 

External  -  The  contractor's  design  engineers,  subject  matter 
experts,  analyst  judgement. 

Process 

When  the  results  of  the  Maintenance  Requirements  Simulation 
model  indicate  that  the  manpower  required  to  maintain  the  system 
under  evaluation  exceeds  the  manpower  constraints  obtained  from 
the  MCEA  or  that  the  system  availability  and  reliability 
requirements  obtained  from  the  SPREA  are  deficient,  the  analyst 
can  use  the  MMAA  to  investigate  potential  solutions  to  the  design 
deficiencies.  The  analyst  will  be  able  to  obtain,  from  the 
Reports  Generator,  a  frequency  distribution  of  component  or 
functional  system  failures,  a  list  of  components  or  functional 
systems  that  caused  a  mission  to  be  missed  or  aborted,  or  other 
information  that  may  indicate  the  reason  for  a  maintenance 
deficiency.  Given  this  information,  the  analyst  can  use  the  MMAA 
as  a  tool  to  estimate  the  effects  of  changes  in  the  Component 
Maintenance  Parameters  on  maintenance  workload  by  modifying  one 
or  more  parameters  and  re-executing  the  simulation  model.  For 
example,  if  the  contractor  could  increase  the  mean  time  between 
failure  of  a  particular  component  or  functional  system  by  10%, 
would  that  change  reduce  the  maintenance  manhour  requirements 
enough  to  meet  the  manpower  constraints?  What  impact  would  such 
a  change  have  on  the  system  availability  or  reliability?  This 
information  can  be  presented  to  the  contractor  for  potential 
resolution  of  the  deficiency. 
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When  presented  with  a  report  of  maintenance  workload 
deficiencies,  the  MMAA  can  also  be  made  available  to  the 
contractor  for  this  kind  of  "what  if?"  analysis. 

Potential  solutions  that  involve  increases  in  personnel 
skill  and  performance  levels  can  be  passed  on  to  the  (MPT)2 
Trade-Off  Analysis  aided  by  Product  6  to  determine  the  impacts  of 
the  solutions  on  personnel  characteristics,  training,  interface 
design,  etc. 

Output 

The  outputs  of  this  step  are  simulation  results  files  that 
contain  the  same  data  obtained  from  the  original  execution  of  the 
Maintenance  Requirements  Simulation  model.  These  results  files 
can  be  used  by  the  Army  analyst  and  the  contractor  to  evaluate 
the  effects  of  potential  solutions  to  maintenance  deficiencies  on 
maintenance  workload.  These  results  files  will  also  be  available 
as  input  to  the  analysis  aided  by  Product  6. 

User  Interface  Issues 


The  user  interface  for  performing  this  step  will  be  the 
spreadsheet-like  Component  Maintenance  Parameter  Templates 
described  in  Steps  1  and  4  and  the  interface  described  in  Step  6 
for  executing  the  Maintenance  Requirements  Simulation  Model. 


4 . 3  MMAA  Software  Elements 


This  section  contains  a  brief  description  of  preliminary 
designs  of  the  software  elements  that  comprise  the  Maintenance 
Manhour  Analysis  Aid  (MMAA) .  These  elements  are  grouped  into  the 
following  categories: 

1.  Templates  -  consist  of  sets  of  menus,  prompts,  and 
spreadsheet-like  interfaces  for  users  to  create  and 
gain  access  to  data  files 

2.  The  Component  Maintenance  Parameter  Library  -  includes 
historical  data  on  maintenance  parameters  of  fielded 
military  weapon  systems. 

3 .  Direct  access  to  military  maintenance  data  bases  - 
consists  of  software  that  is  included  in  the  MMAA  that 
will  give  the  analyst  access  to  selected  data  bases 
that  contain  maintenance  data  on  fielded  systems 
without  leaving  the  MMAA. 
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4.  Data  files  -  store  information  specific  to  the 
evaluation  of  a  proposed  system  design.  Data  files 
store  both  input  and  output  data  that  is  used  and 
produced  by  the  other  software  components. 

5.  The  Maintenance  Requirements  Simulation  Model  -  is  the 
generic  maintenance  network  simulation  model  used  to 
calculate  estimated  maintenance  manpower  requirements. 

Like  the  WAA,  the  MMAA  will  have  an  Application  Manager  that 
is  the  underlying  software  operating  system  that  controls  the 
transfer  of  information  between  all  of  the  software  components. 

Figure  69  illustrates  the  relationships  between  each  of  the 
software  elements  in  the  MMAA. 

4.3.1  The  Templates 

The  Component  Maintenance  Parameter  Template 

This  template  provides  for  the  following  three  different 
functions  to  be  performed  by  the  analyst  within  the  overall 
activity  of  identifying  the  component  maintenance  parameters  of 
the  system  under  evaluation: 

1.  It  provides  the  analyst  with  a  menu  and  prompt  driven 
interface  to  gain  access  to  and  copy  information  from 
the  Component  Maintenance  Parameter  Library. 

2.  It  provides  a  spreadsheet-like  interface  to  let  the 
analyst  easily  copy  and  modify  data  obtained  from  the 
Library  and  enter  data  from  other  sources. 

3.  It  provides  a  mechanism  for  creating,  retrieving,  and 
modifying  data  that  is  stored  in  data  files. 


The  Mission  Scenario  Template 

The  function  of  this  template  is  to  provide  the  analyst  with 
a  menu  and  prompt  driven  interface  to  create,  store,  retrieve, 
and  modify  mission  scenario  data  files  that  are  used  as  input  for 
the  Maintenance  Requirements  Simulation  Model. 

The  Mission  Scenario  Template  also  provides  the  analyst  with 
a  spreadsheet-like  interface  to  enter  the  mean  operational  units 
per  mission  data  for  each  component  in  the  system. 
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Figure  69.  Relationships  Between  Software  Elements  of  the  MMAA 
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4.3.2  The  Reports  Generator 

This  template  will  be  similar  to  a  menu,  prompt,  and  command 
driven  relational  data  base  manager.  It  will  be  used  by  the 
analyst  to  gain  access  to  and  retrieve  data  from  the  Maintenance 
Requirements  Simulation  Model  results  data  base.  Statistical  and 
graphical  analysis  capabilities  will  be  embedded  within  the 
Reports  Generator. 

The  Reports  Generator  will  let  the  analyst  combine  various 
pieces  of  data  and  specify  the  format,  headings,  and  labels  for 
maintenance  manpower  requirements  reports.  The  reports  can  be 
printed  out  and  saved  as  documents  in  maintenance  reports  data 
files. 

4.3.3  The  Component  Maintenance  Parameter  Library 

The  Component  Maintenance  Parameter  Library  is  a  data  base 
file  of  maintenance  parameters  for  individual  components  that 
make  up  major  systems  within  the  Army.  The  data  base  is 
organized  by  functional  systems  within  each  major  system. 

The  analyst  will  be  able  to  use  the  Component  Maintenance 
Parameter  Template  to  locate  and  copy  historical  maintenance 
information  on  component  parameters  that  are  required  as  input  to 
the  Maintenance  Requirements  Simulation  Model.  The  historical 
data  gathered  from  fielded  systems  within  the  military.  The 
analyst  will  use  this  data  as  baseline  estimates  of  maintenance 
parameters  for  proposed  system  designs  that  are  being  evaluated. 

Organization  of  the  parameters  in  the  Library  by  Mission 
Area,  major  system  category,  major  system,  and  functional  system 
will  let  the  analyst  build  a  set  of  baseline  estimates  for  the 
system  under  evaluation  from  a  number  of  different  major  systems 
in  the  field  so  that  the  baseline  estimates  closely  approximate 
the  configuration  of  components  designed  into  the  new  system. 

It  will  be  impossible,  under  the  scope  of  this  effort,  for 
us  to  gather  component  maintenance  parameter  data  from  every 
major  system  fielded  in  every  Mission  Area.  However,  we  will 
develop  and  prioritize  a  list  of  major  systems  from  each  Mission 
Area  and  select  systems  based  on  the  needs  of  the  Army  analysts 
and  the  practicality  of  obtaining  the  data  in  a  time  frame  that 
is  within  the  scope  of  the  (MPT)2  effort.  We  anticipate  that  we 
will  be  able  to  include  Component  Maintenance  Parameters  for  at 
least  one  major  system  in  each  Mission  Area.  We  will  also 
document  and  transfer  the  methodology  for  gathering  and  entering 
the  data  for  other  major  systems  into  the  Component  Maintenance 
Parameter  Library. 
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The  sources  of  data  we  will  use  to  gather  the  Component 
Maintenance  Parameter  data  will  include: 

•  Maintenance  task  analyses  taken  from  Technical  Manuals. 

•  Maintenance  task  allocation  charts. 

•  Maintenance  MOS  and  skill  level  assignments  within  the 
different  maintenance  categories. 

•  Historical  data  on  average  times  for  different 
maintenance  activities. 

•  Maintenance  logs  of  component  and  equipment  failures. 

•  Subject  Matter  Experts. 

Direct  access  to  military  maintenance  data  bases 

In  addition  to  the  Component  Maintenance  Parameter  Library, 
the  MMAA  will  contain  software  that  will  give  the  analyst  access 
to  selected  data  bases  that  contain  maintenance  data  for  fielded 
military  systems.  The  analyst  will  use  this  capability  when 
there  is  no  adequate  comparable  system  component  in  the  library. 

The  information  in  the  maintenance  data  bases (s)  that  are 
selected  for  use  with  the  MMAA  will  require  more  interpretation 
on  the  part  of  the  analyst  than  will  the  data  in  the  library. 

This  is  due  to  the  fact  that  the  data  are  not  a  part  of  the  MMAA 
and  are  therefore  less  MMAA  specific.  However,  the  scope  of 
information  across  a  broad  variety  of  fielded  systems  and  the 
fact  that  these  data  bases  are  continually  updated  with  new  data 
makes  access  to  one  or  more  maintenance  data  bases  desirable  as  a 
fail-back  option  to  Component  Maintenance  Parameter  Library  data. 

In  Task  2  of  the  (MPT)2  effort,  we  will  identify  candidate 
data  bases  for  which  to  develop  direct  links  with  the  MMAA.  One 
of  the  most  promising  candidates  will  certainly  be  the  Sample 
Data  Collection  Data  Base.  DRC  currently  maintains  a  direct  link 
with  the  SDC  Data  Base  and  has  developed  the  software 
architecture  to  convert  SDC  data  tapes  to  a  format  that  is  usable 
for  a  HARDMAN  analysis. 

4.3.4  Data  Files 

Component  Maintenance  Parameter  Files 

These  files  will  contain  the  best  available  estimates  of  the 
maintenance  parameters  for  each  hardware  and  software  component 
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included  in  the  system  design  under  evaluation.  If  available, 
these  files  will  also  contain  the  contractor's  estimates  of 
component  maintenance  parameters.  A  Component  Maintenance 
Parameters  file  is  created  by  the  analyst  either  by  copying 
component  parameters  from  the  Component  Maintenance  Parameters 
Library  or  by  entering  components  and  parameters  directly  into 
the  Component  Maintenance  Parameters  Template.  A  description  of 
each  maintenance  parameter  included  in  the  file  can  be  found  in 
Table  4 . 

The  Component  Maintenance  Parameters  file  is  a  required 
input  for  the  Maintenance  Requirements  Simulation  Model. 

Mission  Scenario  Files 


The  analyst  creates  Mission  Scenario  files  from  the  Mission 
Scenario  Template.  Each  Mission  Scenario  file  contains 
information  on  specific  missions  that  the  system  under  evaluation 
must  perform.  This  file  is  a  required  input  for  the  Maintenance 
Requirements  Simulation  Model.  A  detailed  description  of  the 
contents  of  the  Mission  Scenario  file  can  be  found  in  Section 
4.2.5. 

Simulation  Results  File 

The  Simulation  Results  File  contains  all  of  the  results  of 
the  execution  of  the  Maintenance  Requirements  Simulation  Model. 
This  file  actually  serves  as  a  relational  data  base  file.  The 
final  values  of  all  of  the  variables  and  arrays  that  keep  track 
of  the  cumulative  maintenance  requirements  in  the  simulation 
model  are  stored  in  the  Simulation  Results  File.  It  will  serve 
as  the  input  file  for  the  Reports  Generator  software  component. 

A  detailed  description  of  the  contents  of  the  Simulation 
Results  file  can  be  found  in  Section  4.2.6  and  in  the  discussion 
of  the  Maintenance  Requirements  Simulation  Model  in  Section 
5.2.4. 

Maintenance  Reports  Files 

When  the  analyst  has  executed  the  Maintenance  Requirements 
Simulation  Model  and  used  the  Reports  Generator  Template  to 
create  various  reports  of  maintenance  requirements,  each  report 
can  be  saved  as  a  Maintenance  Report  File.  These  files  are 
simply  copies  of  reports  that  were  generated.  They  are  text 
files  that  can  be  edited  with  a  word  processor  or  text  editor  but 
they  can't  be  recalled  and  modified  with  the  report  generator. 
Maintenance  Reports  files  are  a  convenient  method  of  storing 
reports . 
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4.3.5  The  Maintenance  Requirements  Simulation  Model 


The  Maintenance  Requirements  Simulation  Model  that  is 
embedded  within  the  MMAA  will  model  the  maintenance  requirements 
of  each  component  in  the  new  system  being  evaluated  and  will 
compute  an  estimation  of  the  total  system  maintenance 
requirements  and  an  estimation  of  system  reliability  and 
availability.  Figure  70  is  a  block  diagram  of  the  top  level 
network  in  the  Maintenance  Requirements  Simulation  model.  The 
next  few  pages  will  explain  the  logic,  algorithms,  and  data 
collection  techniques  used  in  the  model  at  a  conceptual  level . 

All  of  the  techniques  and  concepts  described  herein  are  within 
the  current  functional  capabilities  of  the  Micro  SAINT  simulation 
software  that  will  be  used  to  build  the  embedded  computer  model. 

Each  oval  or  rectangular  shape  in  the  illustration 
represents  a  task  in  the  top  level  network.  The  arrows  between 
the  nodes  indicate  the  sequence  of  execution.  The  simplicity  of 
this  top  level  network  is  apparent.  However,  the  rectangular 
node  labeled  "perform  maintenance"  represents  a  sub-network  of 
tasks . 

The  following  paragraphs  discuss  the  individual  tasks  in  the 
model . 

Task  1  -  Calculate  Maintenance  Schedule 

The  task  labeled  1.0  will  calculate  the  number  of 
operational  units  before  the  first  failure  requiring  corrective 
maintenance  for  each  component  in  the  system  being  evaluated. 

This  wi^ 1  be  accomplished  by  a  Micro  SAINT  function  that  will 
search  the  component  parameter  matrix  that  was  input  by  the 
analyst  for  each  maintenance  action  whose  "type"  is  "corrective". 
The  function  will  then  calculate  an  exponentially  distributed 
random  number  using  the  "mean  operational  units  between  failure" 
for  that  action  and  component.  The  actual  number  of  operational 
units  to  be  used  for  the  simulated  first  corrective  maintenance 
for  each  component  will  be  stored  in  a  two-dimensional  variable 
array  along  with  the  binary  value  from  the  Component  Maintenance 
Parameter  matrix  that  indicates  whether  or  not  that  particular 
component  failure  is  critical  enough  to  cause  the  mission  to  be 
aborted.  The  current  number  of  operational  units  at  this  point 
in  the  simulation  (at  this  point  zero)  will  also  be  stored.  The 
last  element  for  each  component  in  the  array  is  a  binary  value 
that  indicates  when  the  current  number  of  operational  units  has 
reached  the  value  calculated  for  the  first  component  failure. 
Figure  71  is  an  illustration  of  the  elements  in  the  corrective 
maintenance  array. 
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Figure  70.  Top  Level  Network  in  the  Maintenance  Requirements 
Simulation  Model 
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Figure  71.  Corrective  Maintenance  Array 
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A  second  variable  array  will  contain  values  to  be  used  for 
simulating  planned  maintenance.  The  number  of  operational  units 
between  maintenance  actions  that  are  "planned"  will  be  taken 
directly  from  the  component  matrix  since  planned  maintenance  is 
scheduled  on  a  regular  basis.  The  variation  in  the  time  that 
planned  maintenance  is  actually  conducted  is  modeled  by 
performing  planned  maintenance  only  between  missions.  This  array 
will  also  contain  an  element  that  indicates  the  current  number  of 
operational  units  since  the  last  occurrence  of  this  planned 
maintenance  action  and  a  binary  ’'flag"  (1  or  0)  to  indicate  when 
the  component  is  ready  for  the  planned  maintenance. 

Task  2  -  Perform  Mission 


The  function  of  this  task  is  to  increment  variables  that 
indicate  the  current  state  of  the  simulation  model.  Following  is 
a  list  of  variables  that  are  incremented  in  task  2: 

1.  A  counting  variable  that  keeps  track  of  the  number  of 
missions  started  is  incremented  by  one. 

2.  The  number  of  operational  units  for  each  component  per 
mission  according  to  the  mission  scenario  information 
that  was  entered  by  the  analyst. 

3 .  The  mission  mean  time  and  standard  deviation  are  used 
to  calculate  a  normally  distributed  random  number 
representing  the  actual  (simulated)  execution  time  for 
"Perform  Mission". 

4.  The  "current  number  of  operational  units"  elements  of 
the  maintenance  schedule  arrays  for  planned  and 
corrective  maintenance  (discussed  above)  for  each 
component  are  incremented  by  the  number  of  operational 
units  per  mission  obtained  from  the  mission  scenario 
data.  For  example,  if  the  mission  scenario  data 
indicates  that  a  component  is  operated  for  50%  of  a 
mission,  and  the  simulated  mission  time  is  2.5  hours, 
the  current  number  of  operational  units  for  that 
maintenance  action  is  incremented  by  1.25  units. 

5.  For  planned  and  non-critical  corrective  maintenance 
actions,  the  current  number  of  operational  units  is 
compared  to  the  number  of  operational  units  for  the 
next  failure  (or  planned  maintenance) .  If  the  current 
operational  units  is  greater  than  or  equal  to  the  value 
for  the  next  failure,  the  flag  element  indicating  a 
need  for  maintenance  is  changed  from  0  to  1. 
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Corrective  maintenance  that  causes  the  mission  to  be 
aborted  will  cause  task  2  to  be  interrupted  and  the 
maintenance  will  be  performed  immediately  (refer  to  the 
dotted  line  on  the  network  diagram) .  In  this  case,  the 
operational  units  per  mission  for  the  other  components 
in  the  system  will  only  be  incremented  by  the  percent 
of  the  mission  that  was  completed. 

6.  When  a  mission  is  aborted,  a  variable  counting  the 

total  number  of  aborted  missions  is  incremented  by  one. 
The  value  of  this  variable  will  be  used  to  calculate  a 
measure  of  the  system  reliability  using  the  following 
equation: 

reliability  *  (TS  -  TA)  /  TS 
where : 

TS  =  total  missions  started 
TA  *  total  missions  aborted 

Reliability  in  the  above  equation  is  the  probability  of 
the  mission  being  completed  without  aborting. 

Task  3  -  Maintenance  Recruired  ? 

This  is  a  zero  time  task  whose  function  is  to  sort  through 
the  variable  arrays  to  determine  if  any  of  the  planned  or  non- 
critical  maintenance  flags  are  egual  to  1  (one) .  Task  3  is  a 
decision  task.  If  any  of  the  component  flags  equals  one,  it  is 
followed  by  the  "Perform  Maintenance"  network  and  by  the  task 
labeled  "Standby  Time".  This  is  to  establish  a  "window"  of  time 
within  which  all  maintenance  must  be  completed  to  avoid  missing 
the  next  scheduled  mission. 

If  all  of  the  component  flags  in  the  two  variables  are  equal 
to  C  (zero) ,  only  task  5  ("Standby  Time")  is  executed  next. 

Sub-network  4.0 


This  sub-network  simulates  the  performance  of  all 
maintenance  activities.  The  maintenance  for  each  component  whose 
"flag"  in  the  planned  or  corrective  maintenance  variable  array  is 
performed  in  parallel.  To  calculate  the  actual  number  of  people 
needed  for  each  maintenance  job,  the  model  will  first  generate 
the  maintenance  times  for  each  task  and  then  sum  all  of  the  tasks 
that  are  to  be  performed  by  a  single  maintenance  job.  This  value 
is  compared  to  the  time  allotted  for  the  maintenance  window  to 
determine  the  number  of  people  needed  for  each  job.  Figure  72  is 
a  block  diagram  of  the  tasks  in  the  "perform  maintenance"  sub¬ 
network. 
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Figure  72.  "Perform  Maintenance"  Sub-network 
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When  the  maintenance  for  a  component  has  been  completed,  the 
variable  array  element  containing  the  cumulative  operational 
units  between  maintenance  is  re-set  to  zero.  If  the  corrective 
maintenance  was  performed,  a  new  exponentially  distributed  random 
number  is  generated  for  the  number  of  operational  units  until  the 
next  failure  and  assigned  to  that  array  element  in  the  corrective 
maintenance  array. 

Task  4.1  is  a  "dummy"  task  used  to  start  each  of  the 
component  maintenance  tasks  that  have  flag  values  equal  to  1 
(one).  Task  4.1  also  assigns  the  value  of  1  (one)  to  another 
flag  (referred  to  later  as  the  "overall  maintenance  flag") 
indicating  that  maintenance  (of  some  kind)  has  started.  Task 
9999  will  not  execute  until  all  of  the  maintenance  tasks  have 
completed.  It  is  a  zero  time  task  that  resets  the  maintenance 
flag  to  0  (zero)  to  indicate  that  all  maintenance  has  been 
completed. 

The  time  it  takes  to  perform  each  individual  maintenance 
action  is  a  normally  distributed  random  number  that  is  calculated 
from  the  mean  and  standard  deviation  values  for  repair  times  that 
are  in  the  Component  Maintenance  Parameter  File.  The  calculated 
time  is  also  used  to  increment  the  variables  that  represent  the 
cumulative  number  of  manhours  for  the  appropriate: 

•  Maintenance  job  (MOS,  skill  level  and  category). 

•  Maintenance  type. 

•  Maintenance  level 

•  System  component 

Task  5  -  Standby  Time 

This  task  simulates  the  time  between  scheduled  missions.  It 
follows  task  3  whether  or  not  maintenance  is  required.  The 
execution  time  for  task  5  is  generated  from  a  function  that  uses 
the  following  mission  scenario  values: 

•  Mean  time  between  missions 

•  Standard  deviation  between  missions 

•  Number  of  missions  per  day 

The  main  purpose  for  the  "Standby  Time"  task  is  to  establish 
"windows"  of  time  within  which  all  maintenance  must  be  completed 
without  missing  the  next  scheduled  mission.  At  the  end  of  task  5 


El-197 


the  value  of  the  "overall  maintenance  flag"  is  checked.  If  the 
value  of  the  flag  is  1  (one) ,  it  indicates  that  some  maintenance 
is  still  being  performed. 

When  this  is  the  case  two  things  happen: 

1)  A  variable  storing  the  number  of  missed  missions  is 
incremented  by  one. 

2)  A  new  window  is  established  by  generating  an  execution 
time  for  the  mission  that  was  missed  and  adding  it  to 
another  randomly  generated  standby  time. 

Task  5  keeps  following  itself  until  all  of  the  maintenance 
has  been  completed.  Then  it  is  followed  by  the  performance  of 
the  next  mission.  The  number  of  missed  missions  is  used  to 
calculate  a  measure  of  the  system  availability  at  the  end  of  the 
simulation  using  the  following  equation: 

availability  -  TM  /  (TS  +  TM) 

where : 

TS  *  total  missions  started 
TM  -  total  missions  missed 

When  the  system  clock  is  greater  than  or  equal  to  the  number 
of  days  covered  by  the  simulation,  as  indicated  in  the  mission 
scenario  data,  task  5  is  followed  by  the  last  task  in  the  model. 

When  the  last  task  is  executed,  the  values  of  all  of  the 
variables  used  to  store  maintenance  manhour  requirements  will  be 
stored  in  a  Simulation  Results  File  data  base.  The  analyst  can 
access  this  data  base  through  the  Maintenance  Reports  Generator 
to  generate  reports  of  the  maintenance  manhour  requirements 
calculated  in  the  simulation  model. 

The  output  of  the  computer  simulation  model  will  be  a 
relational  data  base  of  maintenance  manhour  requirements  that  can 
be  queried  to  report  various  combinations  of  maintenance 
requirements  such  as: 

e  Maintenance  jobs  required. 

•  Maintenance  tasks  (maintenance  action  by  component)  per 

maintenance  job. 

e  Manhours  by  maintenance  job. 

•  Maintenance  headcount  data  per  job. 

•  Manhours  by  system  component. 

e  System  reliability. 
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•  Component  reliability. 

•  Functional  system  reliability. 

•  System  availability. 


4.4  Estimated  Analysis  Time 

Based  on  the  maintenance  requirements  analysis  that  is 
defined  in  this  section,  we  anticipate  that  a  range  of  40  -  80 
hours  of  analyst  time  will  be  required  for  a  typical  major  system 
acquisition. 
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CONCEPT  FOR  A  DECISION  AID  TO  EVALUATE  SYSTEM  DESIGN  MANPOWER  REQUIREMENTS 


PROJECT  OVERVIEW 


Project  Requirement 

The  Army  Research  Institute  (ARI)  has  initiated  a  three  phase  program 
to  develop  six  decision  aid  products  for  implementing  the  Army's  MANPRINT 
(Manpower  Personnel  Integration)  program.  This  submission  responds  to  the 
first  phase  of  the  requirement:  development  of  a  detailed  concept  paper. 
Specifically,  the  present  paper  addresses  only  Product  5  --  a  decision  aid 
to  evaluate  the  manning  requirements  (estimated  crew  size)  for  a  system 
given  the  initial  system  design.  This  product  will  support  manpower, 
personnel,  and  training  decisions  concerning  whether  or  not  to  commit  to 
system  development. 


The  MANPRINT  Tools  Research  and  Development  Program 

The  purpose  of  this  ARI  research  program  is  to  design,  develop  and 
produce  six  MANPRINT  decision  aiding  products.  It  will  be  useful  to  first 
describe  the  nature  of  the  intended  products  of  the  program.  Figure  1  i' 
provided  as  a  reader's  reference  for  this  overview. 

Products  1  to  4  of  the  program  involve  the  pre-design  phase  of  system 
development.  These  products  are  intended  to  influence  system  designs. 
Product  1  focuses  on  defining  system  requirements,  including  system 
performance  criteria  and  reliability,  availability,  and  maintainability 
requirements.  Should  the  six  tools  be  developed  and  become 
institutionalized,  the  front  end  analysis  output  of  Product  1  could  be 
instrumental  to  all  subsequent  products. 

Products  2.  3  and  4  are  also  intended  as  designer  decision  aids.  They 
develop  pre-design  estimates  to  help  identify  constraints  which  may  affect 
the  design  process.  Product  2  estimates  maximum  crew  size,  Product  3 
estimates  limiting  soldier  characteristics,  and  Product  4  focuses  on  likely 
available  training  for  new  system  personnel. 

Products  5  and  6  are  to  be  implemented  once  an  initial  system  design  is 
available.  These  products  are  intended  to  eval uate  system  designs.  Product 
5  (the  subject  of  this  paper)  w  11  cluster  system  performance  tasks  into 
required  jobs  and  identify  the  crew  size  needed  to  operate  and  maintain  the 
system.  With  it,  a  user  will  also  be  able  to  determine  whether  a 
predetermined  crew  size  can  meet  system  performance  requirements.  With  the 
output  of  Product  5,  Product  6  will  determine  personnel  characteristics 
required  to  fill  operator  and  maintainer  crews  and  identify  any  deficit 
between  required  and  available  personnel. 

There  is  an  evident  logic  in  the  relationship  among  these  products  as 
they  flow  from  aiding  the  design  process  to  aiding  the  decision  to  commit  to 
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system  development.  Yet,  they  must  be  able  to  operate  as  independently  as 
possible  and  be  convenient  to  use.  These  products  will  help  the  Army  insure 
that  its  soldiers  will  be  able  to  operate  and  maintain  system  hardware  and 
software  in  required  numbers  and  at  levels  of  performance  that  will  ensure 
mission  success. 


Product  5  Overview 

The  purpose  of  Product  5  is  to  serve  as  a  research  and  development 
commitment  decision  aid  once  an  initial  engineered  system  design  becomes 
available.  Specifically,  Product  5  is  to  be  a  tool  capable  of  determining 
crew  size  by  refining  task  clusters  into  crew  operator  and  maintainer  jobs. 
The  tool  will  support  both  predictive  and  prescriptive  interests.  The 
primary  function  of  the  system  is  to  predict  the  minimum  number  of  personnel 
required  to  achieve  intended  system  performance.  The  user  will  be  able  to 
answer  the  question  "how  many  people  are  required  to  operate  and  maintain 
this  system,  and  what  are  the  tasks  in  their  jobs?"  A  user  will  also  be 
able  to  use  the  tool  to  determine  the  job  activities  of  each  member  in  a 
crew  of  a  given  size.  For  example,  a  user  could  answer  a  question  such  as 
"Could  a  crew  of  2  man  the  system?"  Further,  the  user  of  this  MANPRINT  tool 
will  be  able  to  determine  manpower  requirements  as  a  function  of  variables 
such  as  criteria  or  conditions  under  which  performance  occurs.  This  will 
permit  the  engineered  design  to  be  explored  for  cost-effective  manning/ 
design  alternatives  and  prospective  effects  on  system  performance. 

Product  5  will  first  define  mission-function  performance  objectives  and 
system  tasks  required  to  attain  the  objectives.  Through  statistical 
analysis,  these  data  will  be  reduced  to  task  "clusters"  representing  system 
operator  and  maintainer  operations  to  be  performed.  The  tool  will  then 
convert  the  organized  task  clusters  into  distinct  jobs  to  determine  minimal 
crew  size.  These  processes  are  shown  in  Figure  2,  along  with  input  data 
required  and  the  intended  output. 

Before  addressing  the  methodology  of  Product  5,  it  is  appropriate  here 
to  conceptualize  the  product's  envisioned  form.  Product  5  is  envisioned  as 
a  computer  based  system.  It  is  known  that  ARI  would  prefer  a  computer-based 
tool  that  could  be  accommodated  on  a  personal  computer,  such  as  the  IBM-AT, 
in  order  to  encourage  convenient  implementation  and  wide  spread  use  of 
Product  5.  The  AT  form  of  computer  with  the  new  gigabyte  memory  cards  and  a 
20  -  30  MB  hard  drive  is  an  entirely  feasible  medium  for  the  proposed 
decision  aid.  Largely,  the  system  will  be  a  data  base  management  system 
with  convenient  but  powerful  editing  capabilities.  It  will  also  possess 
specific  statistical  analysis  and  data  manipulation  routines  yielding  fully 
interpreted  output.  The  Product  will  be  able  to  forecast  crew  size  and 
alter  input  variables  in  exploratory  fashion  for  advanced  applications. 

It  is  expected  that  the  software  program  will  be  menu  driven.  Input 
data  will  be  keyed  in  or,  if  available  on  tape,  read  in.  Input  data 
requests,  processing  rationale,  and  output  should  be  logical  and 
comprehensible  for  MPT  personnel.  As  regards  user  training,  our  preference 
is  for  a  system  that  is  primarily  self-taught  (on-screen  help  and  user 
manual),  supplemented  with  periodic  user  workshops  and  newsletters  which 
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share  user  techniques  and  solutions  to  analytic  problems,  in  the  spirit  of 
special  interest  "user  groups." 


Uniqueness  of  This  Approach 

The  Product  5  approach  described  in  this  concept  paper  is  based  around 
two  features:  user-friendliness  and  comprehensiveness  in  the  concept  behind 
the  algorithms.  The  approach  can  be  described  as  a  "friendly  task¬ 
clustering  precedence-network"  analysis. 

The  product  is  friendly  in  several  aspects.  First,  a  user  can  become 
as  involved  as  he  or  she  wants  in  the  process.  A  user  may  input  very 
detailed  free  text  data  gathered  from  a  number  of  sources,  may  input  data 
from  system-stored  templates,  or  may  select  system  defaults.  Second,  the 
user  can  stop  the  product's  process  following  task-clustering  (the  first 
algorithm  application),  obtain  a  printout,  and  review  the  data  before  going 
on  to  the  precedence-network  analysis  (the  second  and  final  algorithm 
application).  The  user  can  also  omit  this  step  if  desired.  Third,  the 
experienced  user  can  conduct  advanced  applications  using  the  product  by 
manipulating  input  data  to  assess  its  affects  on  crew  size.  Fourth,  the 
system  will  be  menu-driven.  User  requirements  will  be  translated  into  easy- 
to-use  and  understand  interfaces.  In  summary,  the  system  allows  the 
interested  user  to  become  involved  in  the  process,  but  can  also  provide 
output  with  minimal  input  from  the  user. 

The  concept  behind  the  algorithms  of  Product  5  represents  a  new  level 
of  comprehensiveness  in  generating  manpower  estimates.  Product  5  associates 
tasks  with  system  performance  objectives,  and  then  clusters  similar  tasks. 
Only  then  does  Product  5  create  unique  jobs  using  a  network  or  precedence 
analysis.  Previous  approaches  have  created  jobs  from  tasks  based  largely  on 
time  and  precedence  using  work  flow  process  diagrams,  without  regard  to  the 
relation  of  tasks  to  system  objectives  or  to  other  tasks. 


Concept  Paper  Outline 

This  paper  presents  the  technical  approach  in  eight  sections.  First, 
the  product's  outputs  are  discussed  to  give  a  reader  a  clear  indication  of 
the  product's  goals.  Next,  input  data  requirements  and  data  sources  are 
described.  The  user  will  need  access  only  to  standard  government  documents. 
It  will  be  seen  that  the  product  will  produce  output  which  increases  in 
quality  with  the  quality  of  the  input  data.  Thus  the  product  can  be  used  at 
several  points  in  the  materiel  acquisition  process.  The  section  on  process 
and  algorithms  describes  the  system  in  two  steps:  the  formation  of  task 
clusters,  and  the  definition  of  jobs  from  task  clusters.  Next,  user 
services  are  described.  These  include  the  time  required  for  the  user  to 
generate  an  output,  embedded  training  for  the  user,  and  a  user  acceptance 
plan.  Finally,  general  plans  for  product  development  and 
institutionalization  are  presented. 
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OUTPUT  AVAILABLE  FROM  PRODUCT  5 

Product  5  employs  a  two-step  process  of  data  analysis.  First,  similar 
tasks  are  clustered,  and  second,  jobs  are  formed.  The  terminal  output  is 
the  result  of  the  second  step.  Intermediate  outputs  are  produced  during  the 
first  step. 


Terminal  Output 

Product  5  produces  one  primary  terminal  output:  the  number  of  jobs 
required  to  operate  and  maintain  the  system,  the  tasks  to  be  performed  by 
each  person,  and  task  times.  The  output  will  summarize  the  quality  of  the 
input  data  and  advise  the  user  how  to  improve  the  manpower  estimate!  The 
user  can  obtain  this  output  in  three  contexts:  (1)  under  expected 
conditions  of  system  operation,  (2)  under  changes  in  expected  operating 
conditions,  and  (3)  under  contrived  operating  conditions  for  sensitivity 
analysis.  These  contexts  are  described  below. 

The  first  context  for  Product  5  output  is  under  normal  operating 
conditions.  In  this  context  the  user  can  answer  the  question  "how  many 
operators  and  maintainers  are  required  to  man  this  system,  under  normal  or 
expected  operating  conditions  and  what  are  the  tasks  in  their  jobs?"  In 
this  case,  the  user  will  input  data  which  reflect  the  most  probable  system 
operating  conditions,  given  the  available  documentation.  The  system  will 
provide  the  "best"  configuration  of  jobs  and  tasks,  based  on  task 
similarities  and  optimal  resourse  allocation  algorithms.  In  addition, 
alternative  job  configurations  which  meet  the  same  system  requirements,  if 
any,  will  be  provided.  These  alternative  configurations  would  be  derived  by 
"shuffling"  the  tasks. 

The  second  context  for  Product  5  output  is  under  changed  operating 
conditions.  The  user  could  use  this  output  to  answer  questions  such  as 
"will  night  time  operations  increase  manpower  requirements?"  The  user 
enters  these  conditions  as  input  data.  Using  this  example,  the  user  could 
simply  change  day  time  conditions  previously  entered  to  night  time,  and  run 
the  system  again.  The  system  will  list  the  jobs  which  would  result  from 
changes  in  mission  timeline,  production  output  rates,  and  frequency  of  task 
occurrence.  Stress  (increases  in  system  demands)  added  to  system 
performance  affects  the  job  configurations,  and  the  proposed  system  will 
produce  output  sensitive  to  those  factors. 

The  third  context  for  Product  5  output  is  to  answer  a  question  such  as 
"can  3  people  operate  the  system  under  normal  conditions,  or  will  their  task 
loads  be  too  great?"  The  Product  5  user  can  manipulate  input  data  in  order 
to  cause  changes  in  the  output  in  order  to  conduct  sensitivity  analyses. 

The  system  will  not  work  in  reverse,  that  is,  the  user  can  not  input  a  given 
crew  size,  but  the  user  can  change  any  of  the  four  product  inputs  (system 
performance  objectives,  task  list,  sequence,  and  times)  until  the  output 
shows  the  crew  size  of  interest.  In  addition,  task  to  job  allocations  will 
be  made  such  that  a  worker  will  meet  or  at  least  minimize  deviation  from 
performance  requirements. 
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Intermediate  Ouput 

The  user  can  request  printouts  (or  on-screen  reports)  at  intermediate 
points  in  the  process.  The  user  may  request  a  printout  of  all  data  entered: 
system  mission,  system  performance  objectives  by  component,  associated 
tasks,  sequenced,  with  times.  The  user  may  also  request  the  matrix  of 
"system  performance  objectives"  by  "tasks"  which  is  developed  by  the  user 
with  help  from  the  system.  Creating  this  matrix  is  the  first  step  in  the 
Product's  2-step  process.  The  user  may  wish  to  examine  the  matrix  before 
processing  continues,  and  make  changes  as  needed. 

The  user  may  also  request  the  actual  task  clusters  produced  by  the 
system,  although  they  may  not  be  of  interest  to  many  users.  From  these 
clusters  unique  jobs  are  formed  in  the  second  step  of  the  system's  process. 
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INPUT  DATA  REQUIREMENTS  AND  DATA  SOURCES 


Product  5  Use  Purina  the  Acquisition  Process 

It  is  instructive  to  describe  when  in  the  materiel  acquisition  process 
Product  5  is  used  to  greatest  effectiveness.  Figure  3  shows  that  the  first 
use  of  Product  5  occurs  when  early  design  documents  are  available.  As  more 
information  becomes  available,  Product  5  may  be  used  again  and  again  to 
determine  if  the  system's  manpower  requirements  are  acceptable. 

In  the  spirit  of  the  MANPRINT  program,  the  most  important  uses  of 
Product  5  occur  before  the  decision  about  funding  prototype  development. 
During  this  time,  Product  5  output  is  used  to  evaluate  the  new  system's 
acceptability  in  the  area  of  manpower  requirements.  With  Product  5  output, 
the  Army  can  order  system  design  changes  before  the  system  is  built. 
However,  Product  5  may  also  be  used  after  the  prototype  funding  decision  to 
assure  that  actual  system  manpower  requirements  match  projected  manpower 
requirements. 


Input  Data  Required  from  the  User 

As  shown  earlier  in  Figure  2,  the  inputs  required  by  Product  5  are: 

1.  system  performance  objectives 

2.  list  of  system  tasks  for  operators  and  maintainers 

3.  the  sequence  of  system  tasks 

4.  task  times  for  each  operator  and  maintainer  task 

Product  5  evaluates  the  manpower  requirements  of  a  system  design,  and  all  of 
these  data  are  part  of  a  system  design. 

Figure  4  summarizes  the  four  input  data  requirements  and  data  sources. 
Each  data  requirement  and  its  sources  are  discussed  in  this  section. 

System  designs  mature  over  time.  Data  available  early  in  system  design 
are  general  and  of  a  draft  nature.  As  analyses  continue,  more  detailed  data 
become  available.  Government  requirement  documents  and  analyses  undergo 
iterations.  When  a  system  is  fielded,  actual  test  data  are  available.  As 
shown  in  Figure  5,  Product  5  manpower  estimates  improve  with  the  quality  and 
completeness  of  the  input  data.  The  figure  shows  a  steep  then  a  shallower 
increase  in  output  quality.  Figure  5  also  shows  that  Product  5  can  provide 
manpower  estimates  early  in  the  system  design  process. 

Product  5  is  designed  to  accept  input  data  ranging  in  quality  and 
quantity.  Thus,  a  user  can  obtain  an  output  from  Product  5  at  a  number  of 
points  in  system  design  development.  Of  the  four  input  data  requirements, 
system  performance  objectives,  system  tasks,  and  task  sequence  are  specific 
to  the  particular  system  design  under  study.  The  user  may  obtain  design 
documents  with  these  data,  or  could  enter  any  objectives,  tasks,  and 
sequences  desired.  Data  on  task  times  are  less  dependent  on  the  nature  of 
the  system  under  study  and  are  difficult  to  obtain  from  design  documents 
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TRADITIONAL:  PROGRAM  CONCEPT  DEMONSTRATION  /  FULL  SCALE  PRODUCTION 

INITIATION  -0-  EXPLORATION  -I-  AND  /  -II-  DEVELOPMENT  -III-  AND 
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Figure  3.  Product  5  Use  in  Materiel  Acquisition  Process. 
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Figure  4.  Product  5  Data  Requirements  and  Sources. 
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Figure  5.  Product  5  Output  Accuracy  Relates  to  Input  Data  Quality. 


until  late  in  system  design  development.  Therefore,  Product  5  will  contain 
a  hard-wired  data  base  of  task  times  to  be  used  as  a  default  if  the  user 
does  not  have  task  time  data. 


Macro-Structures  for  Input  Data 

It  is  expected  that  input  data  available  to  the  Product  5  user  in 
system  design  documents  will  take  many  forms.  Some  data  will  be  inaccurate 
or  missing.  Over  time,  system  design  documents  as  well  as  the  output  from 
Product  1  may  come  to  provide  the  Product  5  user  with  immediately  usable 
data.  However,  at  least  the  first  several  cadres  of  Product  5  users  will 
require  assistance  in  entering  data  in  the  correct  formats.  For  example, 
system  performance  objectives  must  be  stated  in  terms  of  their  goal 
statement,  conditions  of  performance,  and  performance  criteria.  Guidance 
for  entering  this  information  (e.g.,  Mager's  1975  guidelines)  will  have  to 
be  applied  during  input.  To  do  this,  the  program  will  present  prompts  which 
aid  the  user  to  enter  each  part  of  the  performance  objective  in  acceptable 
form.  Likewise,  a  structured  "help/prompt"  routine  will  be  employed  for 
entering  the  task  list,  task  sequence,  and  task  times.  This  structured 
approach  will  make  evident  to  the  user  where  needed  details  are  absent  and 
further  input  data  are  required. 

A  second  structuring  mechanism  will  be  used  by  Product  5.  This 
structure  will  assist  the  Product  5  user  enter  performance  conditions  and 
task  data,  which  could  be  vague  or  absent  from  initial  system  design. 

Kaplan  and  Crooks  (1980)  developed  a  "task  template  taxonomy"  which  may  be 
used  to  delineate  tasks  and  system  performance  conditions  when  these  data 
are  needed  but  missing.  The  taxonomy  is  presented  in  Appendix  A.  (A 
similar  taxonomy  is  presented  in  Kaplan,  Crooks,  Sanders,  and  Dechter, 

1980). 

The  Kaplan/Crooks  taxonomy  catalogues  system  functions  within  system 
missions  and  permits  the  user  to  identify  tasks  which  reflect  what  the 
function  must  accomplish  for  both  operator  and  maintainer  roles.  The 
taxonomy  provides  the  Product  5  user  with  a  front-end  analysis  based  on 
system  missions  without  regard  to  MOS.  The  taxonomy  also  provides  a 
comprehensive  range  of  conditions  under  which  a  system  might  operate.  To 
solve  the  problem  of  vague  or  absent  task  and  performance  objective 
information,  it  is  proposed  that  the  Kaplan/Crooks  taxonomy  be  automated  as 
a  macrostructure  for  Product  5.  The  template  is  general,  and  for  example, 
describes  tasks,  not  subtasks.  The  template  should  be  adequate,  however, 
for  the  decision  aiding  purposes  of  Product  5.  The  user  will  be  directed 
through  the  Kaplan/Crooks  taxonomy  to  retrieve  tasks  descriptive  of  the 
system  mission  and  function. 

It  is  proposed  that  the  Kaplan/Crooks  taxonomy  also  provide  structure 
to  the  performance  conditions  data.  The  conditions  list  contained  in  the 
taxonomy  is  comprehensive.  The  user  could  review  mission/function 
statements  and  search  the  list  in  menu  fashion  to  makr  all  relevant 
conditions  which  apply.  The  process  can  be  easily  accommodated  on  the  PC- 
AT. 
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Input  Data  for  System  Performance  Objectives 


Data  on  system  performance  objectives  are  available  from  at  least  four 
sources.  These  source  documents,  listed  in  order  of  their  chronological 
availability,  are  the  (1)  Justification  for  Major  System  New  Starts,  JMSNS, 
(2)  the  Operational  and  Organizational  Plan,  O&O,  (3)  the  Required 
Operational  Capability  document,  ROC,  and  (4)  documents  from  the  Integrated 
Logistics  System.  Each  document  is  described  below.  Examples  of  some  of 
the  documents  are  presented  to  give  the  reader  a  sense  for  the  level  of 
detail  available  in  the  documents. 

Justification  for  Major  System  New  Starts.  The  JMSNS  is  a  requirements 
document  developed  by  the  TRADOC  combat  developer,  with  input  from  the 
material  developer,  training  developer,  manpower  and  personnel  planner,  and 
logistician.  The  JMSNS  identifies  and  supports  the  need  for  a  new  or 
improved  mission  capability  when  it  may  cost  more  than  $200  million  in 
research,  development,  test,  and  evaluation  or  $1  billion  in  procurement  (FY 
80  $).  The  document  provides  required  system  performance  objectives  which 
can  be  used  by  the  Product  5  user.  The  documents  are  stored  at  the 
respective  TRADOC  proponent.  Once  a  JMSNS  is  approved,  design  development 
continues.  The  information  in  a  JMSNS  is  similar  to  the  information 
provided  by  the  O&O  plan  described  below. 

Operational  and  Organizational  (O&O)  Plan.  The  O&O  plan  is  generated 
for  all  systems,  major  and  non-major.  This  document  is  generated  and 
approved  before  the  system  Project  Manager  and  Project  Manager  Office  are 
designated,  but  the  O&O  plan  is  improved  iteratively.  The  O&O  plan  is 
written  by  a  special  task  force,  special  study  group,  or  acquisition  team  at 
the  TRADOC  proponent.  The  O&O  plan  describes  how  the  system  will  be  used, 
where  it  will  be  used,  weather  and  climate  considerations,  battlefield 
conditions,  and  the  types  of  units  that  will  use  and  support  the  system. 

The  Test  and  Evaluation  Master  Plan.  (TEMP),  included  in  the  O&O  plan, 
describes  the  new  system  performance  objectives  and  system  mission,  and 
outlines  the  developmental  and  operational  test  plans.  The  TEMP  is  an 
important  document  and  contains  useful  information  for  the  Product  5  user. 
Excerpts  from  TEMP  for  the  M109  howitzer  improvement  program  an  presented  in 
Appendix  B  to  show  the  reader  that  Product  5  input  data  can  be  extacted  from 
the  document.  For  example,  in  the  area  of  mission  performance,  Issue  #1  in 
the  TEMP  shown  in  Appendix  B  is  "Is  the  fire  support  provided  by  the  HIP 
responsive?  The  goal,  conditions,  criteria,  and  source  of  data  are 
provided.  In  this  case,  the  goal  is  "to  provide  fire  support  for  maneuver 
forces."  The  conditions  are  "both  open  and  close  configurations,  and  in  its 
backup  manual  mode  of  operations  for  emplacement,  lay,  and  firing."  The 
criteria  are  "upon  receiving  a  call  to  fire  from  a  target  acquisition  source 
on  fire  commands  from  a  fire  direction  center,  the  median  time  for  an 
emplaced  HIP  to  fire  the  initial  round  of  the  mission  must  be  less  than  30 
seconds,  or  45  seconds  for  high  angle  missions."  The  TEMP  in  Appendix  B 
addresses  14  issues  with  similar  specificity. 

The  Concept  Formulation  Package  of  an  0&0  plan  consists  of  Trade-off 
Analyses  (TOA),  Trade-off  Decision  (TOD),  and  Best  Technical  Approach  (BTA), 
which  are  prerequisite  to  the  Cost  and  Operational  Effectiveness  Analysis 
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(COEA),  which  is  also  part  of  the  Concept  Formulation  Package.  The  COEA  is 
one  of  the  major  documents  involved  in  making  the  prototype  funding 
decision.  The  COEA  will  provide  the  Product  5  user  with  the  tasks  and 
missions  to  be  performed,  threat  and  conditions  under  which  the  task  must  be 
performed,  and  the  logistic  support  concept. 

Section  III,  "Operational  Deployment"  of  the  0&0  plan  presents  system 
performance  objectives.  The  goals  and  conditions  are  also  contained  within 
this  section.  Pages  from  this  section  of  an  0&0  plan  for  the  Howitzer 
Improvement  Program  are  presented  in  Appendix  C.  The  reader  will  see  that 
goal  and  conditions  data  are  available.  In  this  example,  the  goal  statement 
is  "The  HIP  is  operationally  deployed  to  provide  direct  support  fires  to 
committed  units  within  the  division  sector."  The  condition  statement  is 
"HIP  units  are  normally  deployed  in  firing  platoon  position  areas  with 
support  centralized  in  a  battery  support  area.  Platoon  position  areas  will 
be  1000  to  4000  meters  apart." 

Performance  criteria  can  be  found  in  the  "Operational  Mode  Summary/ 
Mission  Profile"  section  of  an  0&0  plan.  Samples  pages  from  the  HIP  0&0 
plan  are  found  in  Appendix  D.  For  example,  a  criterion  statement  is  "For  a 
sustained  rate  of  fire  which  is  expected  to  be  the  operational  mode  40-50% 
of  the  time,  the  following  ranges  are  estimated:  Mobility,  4-10  moves  per 
day  (wartime),  10-25  km;  Firepower:  25-75  missions,  100-300  rounds;  and 
Communications,  1-3  hours  transmit,  2-6  receive.  This  is  the  type  of 
information  that  can  be  used  by  the  Product  5  user. 

Required  Operational  Capabilities  (ROC)  Document.  The  ROC  is  developed 
by  TRADOC  shortly  after  the  0&0  plan  is  developed.  The  ROC  provides  the 
least  essential  system  performance  objectives  in  the  areas  of  operations, 
reliability  and  maintainability,  technical,  personnel  and  manpower, 
training,  safety,  health  hazards,  human  factors  engineering,  logistics,  and 
cost.  These  performance  objectives  must  be  approved  before  production 
begins.  Similar  to  other  design  documents,  the  ROC  is  developed 
iteratively.  Appendix  E  contains  the  outline  used  for  the  ROC.  Goals  and 
conditions  are  described  in  Section  4.  Criteria  in  terms  of  bands  of 
performance  are  listed  in  Section  5. 

Documents  from  the  Integrated  Logistics  Process  (ILSK  The  ILS  process 
produces  documents  which  may  be  of  value  to  the  Product  5  user  later  in  the 
materiel  acquisition  process.  For  example,  the  "Functional  Requirements 
Identification"  document  provides  system  performance  criteria.  Although 
work  on  ILS  documents  begins  during  the  proof  of  principle  phase,  these 
documents  are  generally  not  well  developed  until  after  the  prototype  funding 
decision  is  made.  The  ILS  documents  are  generated  and  housed  at  the  AMC 
sponsor. 


Input  Data  for  Task  Lists 

As  was  the  case  with  system  performance  objectives,  task  lists  for 
operator  and  maintainer  functions  are  provided  in  a  number  of  documents 
which  improve  in  specificity  over  time.  The  documents  are  described  below, 
in  chronological  order  of  their  availability. 
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Qualitative  and  Quantitative  Requirements  Information  (QQPRI).  The 
QQPRI  is  a  document  that  improves  iteratively.  It  is  generated  (in 
conjunction  with  the  Basis  of  Issue  Plan  Feeder  Data,  BOIPFD,  described 
below)  by  the  New  Equipment  Training  section  of  the  major  subordinate 
command  sponsoring  the  new  system.  The  QQPRI  provides  information  about  the 
projected  operator  and  maintainer  positions,  and  it  references  each  position 
to  an  Army  standard  task  list  such  as  AR  611-20.  This  information  is 
contained  in  items  3,  4,  and  5  of  the  QQPRI.  A  QQPRI  for  an  electric  power 
plant  is  provided  in  Appendix  F.  If  there  were  new  or  unique  tasks  for 
electric  power  plant  crews,  they  would  be  listed  in  Item  5. 

The  task  listings  for  operator  and  maintainers  are  reviewed  by  the 
training  developer  at  the  proponent  school.  The  training  developer  fills 
out  the  "Training  Impact  Worksheet"  which  includes  revised  task  lists.  (A 
Training  Impact  Worksheet  is  presented  in  Appendix  6.)  The  new  task 
listings  are  reviewed  by  the  TRADOC  integration  centers  and  HQ  TRADOC.  The 
list  of  approved  tasks  for  operators  and  maintainers  forms  the  basis  for  the 
New  Equipment  Training  Curriculum,  described  below. 

Basis  of  Issue  Plan  (BQIP).  The  first  estimate  of  required  equipment 
capabilities  is  provided  by  the  major  support  centers  and  reported  on  the 
BOIPFD.  In  Item  9  of  the  one-page  BOIPFD  form,  the  principle  item  is  listed 
and  supporting  subsystems  are  listed  with  it.  All  BOIPFD  forms  are  reviewed 
for  accuracy  and  stored  at  the  Equipment  Authorization  Review  Activity  in 
Woodbridge,  Virginia.  Once  BOIPFD  leave  the  major  support  command,  they  are 
collectively  referred  to  as  the  BOIP.  The  BOIP  is  developed  by  the  TRADOC 
proponent,  using  information  from  the  BOIPFD,  QQPRI,  and  New  Equipment 
Training  Plan.  The  Product  5  user  can  refer  to  iterations  of  the  BOIP  for 
changes  made  in  the  MOS  assignments  (Item  18),  and  then  refer  to  an  Army 
Standard  task  list  such  as  AR  611-20  or  updates  to  the  QQPRI  task  lists. 
Appendix  H  contains  a  BOIP  for  a  multipurpose  bayonet. 

TRADOC  submits  the  BOIP  containing  justification  for  the  items  in  the 
system  and  MOS  assignments  to  HQDA,  Deputy  Chief  of  Staff  for  Operations  and 
Plans  (DCSOPS)  for  review  and  approval.  The  BOIP  is  revised  as  new 
information  becomes  available.  DCSOPS  is  the  central  office  of  record  for 
BOIPs.  The  central  data  base  for  BOIPs  is  kept  at  the  Combined  Arms  Center 
Proponency  Office,  Fort  Leavenworth,  Kansas. 


Input  Data  for  Task  Sequences 

New  Equipment  Training  Curriculum.  This  document  presents  the  earliest 
task  sequences.  This  curriculum  is  developed  by  the  New  Equipment  Training 
Section  of  the  major  support  command.  This  curriculum  takes  the  task  list 
from  the  QQPRI,  and  sequences  the  tasks.  This  document  is  part  of  the 
system  design  documents  and  is  evaluated  at  Operational  Testing  I  (OTI), 
between  Milestones  1  and  2,  which  is  pre-prototype.  The  Product  5  user  will 
find  this  a  useful  source  of  task  lists  and  sequences.  The  document 
undergoes  iterations  through  the  testing  process. 

User-Generated  Sequences.  The  user  will  also  have  the  option  of 
developing  a  task  sequence,  in  the  event  that  available  system  design 
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documents  do  not  include  sequences.  The  system  will  prompt  the  user  in  the 
development  of  task  sequences  by  asking  questions  like  "what  does  the 
soldier  do  next?" 


Input  Data  for  Task  Times 

Existing  Sources.  Data  for  maintainer  task  times  are  generated  only 
after  prototype  development,  during  the  Validation  and  Verification  phase. 
These  maintainer  task  time  data  are  stored  at  the  major  support  commands. 

These  data  are  part  of  the  Integrated  Logistics  System,  in  a  report  called 
"Support  Item  Utilization  Summary."  Appendix  I  presents  a  sample  of  this 
document  for  the  FAASV. 

Data  for  operator  task  times  are  not  maintained  as  systematically  as 
the  maintainer  task  times.  This  is  because  task  times  and  workload 
determine  maintainer  manpower  requirements,  but  operator  manpower  requirements 
are  determined  based  on  a  force  structure  analysis.  The  Product  5  user 
would  be  able  to  obtain  operator  task  times  on  a  developing  system,  only  if 
special  studies  (for  example  by  the  Human  Engineering  Laboratory  or  TRADOC 
Analysis  Center  in  White  Sands,  New  Mexico)  had  been  conducted.  However, 
these  data  are  not  provided  in  the  normal  course  of  Army  documentation. 

The  Product  5  user  may  contact  the  contractor  designer  of  the  system 
for  estimates  about  operator  and  maintainer  task  times.  The  Product  5  user 
will  be  advised  that  task  times  obtained  from  the  contractor  may  represent 
ideal  task  times,  not  necessarily  the  actual  task  times  for  the  system 
design. 

Product  5  Task  Times  Data  Base.  Obtaining  task  times  from  existing 
sources  will  pose  a  problem  for  the  Product  5  user.  Therefore,  Product  5 
will  provide  a  hard-wired  data  base  of  operator  and  maintainer  task  times 
for  use  as  default  values  if  none  are  available.  These  values  will  be 
developed  by  the  Product  5  team  without  use  of  Army  subject  matter  experts. 

The  data  base  will  contain  task  times  of  previous  systems,  obtained  from 
TRADOC  proponents  and  test  data.  Use  of  this  data  base  will  not  require  the 
Product  5  user  to  step  through  a  lengthy  analysis  in  order  to  determine  a 
comparable  system.  The  user  will  select  task  times  from  the  data  base 
matched  at  a  gross  task  level. 

Two  approaches  to  the  development  of  the  task  time  data  base  have  been 
considered,  and  one  approach  selected.  One  formal  approach  for  determining 
task  time  data  employs  predetermined  time  systems.  Predetermined  time 
systems  consist  of  elemental  times  associated  with  specific  hand,  arm,  upper 
body,  and  body  motions  required  in  the  accomplishment  of  well  defined  tasks. 
These  times  are  independent  of  the  particular  application  environment.  The 
most  widely  used  predetermined  time  system  is  the  Methods  Time  Measurement 
(MTM)  system.  MTM  consists  of  a  series  of  tables  containing  the  time 
required  to  accomplish  various  motions  as  a  function  of  distance  traveled, 
level  of  difficulty,  weight  of  object  moves  if  applicable,  and  degi  .e  of 
symmetry  of  motion.  Additionally,  a  table  indicating  which  motions  are 
easily  performance  simultaneously  is  provided.  Task  times  can  be  determined 
through  MTM  analysis  by  a  properly  trained  analyst.  This  approach  has  been 
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rejected  for  use  in  establishing  the  Product  5  task  time  data  base  because 
it  is  too  labor  intensive. 

The  approach  to  be  taken  in  developing  the  Product  5  task  time  data 
base  is  use  of  "standard  time  data."  Standard  data  are  task  times  at  a 
higher  level  than  that  generated  by  predetermined  time  systems  and  are 
customized  to  a  particular  application  environment.  Standard  data  are 
maintained  in  a  data  base  where  they  can  be  updated  and  used  as 
appropriate.  Standard  data  can  be  developed  from  predetermined  time  data, 
time  observations,  or  estimates  based  on  other  weapon  systems.  The  Product 
5  team  will  develop  the  initial  data  base  from  task  time  data  from  other 
weapon  systems.  The  advantage  of  standard  data  is  that  they  can  be 
continually  refined,  augmented,  and  maintained  so  that  the  time  data  base 
can  be  used  for  a  variety  of  weapon  systems.  Over  time,  the  Product  5  user 
may  wish  to  update  the  task  time  data  base  with  times  from  system  analyses 
as  they  become  available. 

The  standard  task  time  data  base  for  Product  5  will  be  designed  and 
structured  so  that  it  interfaces  directly  with  the  Product  5  software.  The 
data  base  will  be  designed  as  a  direct  access  data  base,  structured 
similarly  to  the  task  templates  used  to  cluster  tasks  by  performance 
objectives.  All  data  in  the  standard  time  data  base  will  be  coded  to 
indicate  the  source  of  time  data  (e.g.,  previous  weapon  system,  timed 
observation)  so  that  the  user  knows  the  level  of  accuracy  associated  with 
the  task  time  data.  The  user  will  always  be  given  the  opportunity  to 
override  the  task  time  data  drawn  from  the  data  base  and  provide  a  more 
acceptable  task  time.  The  user  will  also  be  guided  to  enter  these  new 
times  into  the  task  time  data  base,  by  providing  the  task,  time,  and  data 
source,  such  as  logistics  documents,  field  testing,  subject  matter  expert 
estimate.  As  Product  5  is  used  more  and  more,  the  standard  task  time  data 
base  will  grow. 


Summary 

The  Product  5  user  must  input  new  system  performance  objectives,  task 
lists,  task  sequences,  and  task  times.  The  Product  will  output  manpower 
estimates  using  data  of  varying  quality.  Early  in  system  design,  input  data 
will  be  sketchy  and  of  a  draft  nature.  As  the  development  cycle  progresses, 
more  accurate  system  data  will  be  available  to  the  Product  5  user.  Still 
later,  the  government  and  contractors  will  more  rigorously  analyze  the 
design.  Once  a  prototype  is  built,  field  study  data  are  available. 

Finally,  full  scale  development  and  deployment  will  provide  actual  system 
data. 


Product  5  is  designed  to  handle  the  sketchy  data  available  early  in 
system  design  as  well  as  complete  data  sets  available  later.  It  provides  a 
macro-structure  for  data  inputs  which  allows  users  to  maximize  the  data 
available.  It  allows  user  to  enter  system  data  from  actual  or  imagined 
system  designs.  As  for  task  times  which  are  usually  only  available  later  in 
the  development  cycle,  the  Product  provides  time  values  which  can  be  used  as 
defaults.  The  quality  of  the  manpower  estimates  generated  by  Product  5  will 
naturally  improve  with  the  quality  of  the  input  data.  However,  the  Product 
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is  intended  to  reach  an  acceptable  level  of  output  accuracy  in  time  to 
significantly  contribute  to  the  prototype  funding  decision. 

A  system  design  is  a  collection  of  documents  that  undergo  iterations  as 
more  is  learned  about  Army  requirements  and  system  capabilities.  Product  5 
uses  as  input  data  important  features  of  system  design  in  order  to  generate 
the  manpower  requirements  of  the  design.  These  manpower  estimates  derive 
from  the  system  itself,  not  from  its  similarity  to  a  previous  system. 
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THE  PROCESS  OF  PRODUCT  5 


Product  5  will  be  capable  of  determining  tasks  and  crew  size  associated 
with  crew  operator  and  maintainer  jobs.  Figure  2  earlier  showed  that  two 
sequential  analyses  will  accomplish  this.  The  first  of  these  analyses 
identifies  the  relationship  among  operator  or  maintainer  tasks  by  clustering 
similar  tasks.  Once  the  tasks  are  clustered,  the  second  analysis  segments 
the  aggregated  tasks  into  work  assignments  (jobs)  to  determine  crew  size. 
This  chapter  is  subdivided  into  two  main  sections  to  thoroughly  describe 
these  two  analyses. 


Analysis  I:  Task  Clustering 

In  this  section  of  the  paper,  the  matter  of  rendering  system- 
descriptive  data  from  system  design  documents  into  a  comprehensive  system- 
to-task  taxonomy  is  addressed.  The  purpose  of  this  procedure  is  to  consider 
all  functions  and  corresponding  performance  objectives  which  the  system  must 
achieve,  to  consider  all  system  tasks  in  relation  to  these,  and  objectively 
cluster  the  tasks  into  a  taxonomy.  The  taxonomy  will  reveal  the 
interrelation  of  the  tasks,  and  thus  all  required  operator  and  maintainer 
operations.  Later  analysis  will  partition  the  task  clusters  into  jobs,  and 
thus  generate  manning  requirements  (i.e.,  crew  size,  described  in  the 
section  on  determining  unique  jobs). 

Overview  of  Task  Clustering.  The  prior  section  of  this  paper  focused 
on  input  data  acquisition.  This  section  elaborates  in  detail  on  the 
specific  nature  of  the  input  data  and  its  manipulation  toward  identifying 
operator  and  maintainer  task  clusters.  A  brief  overview  of  the  key  elements 
of  this  methodology  will  be  useful  prior  to  detailed  discussion.  The  key 
elements  are: 

•  Inputs  to  Task  Clustering: 

1.  Performance  objectives  including  criteria  and  conditions  for 
each  system  function. 

2.  Tasks  associated  with  the  system  component(s)  that  support 
performance  objectives. 

3.  Measure  of  association  between  tasks  and  system  performance 
objectives. 

•  Method  of  Task  Clustering 

1:  Use  of  performance  conditions:  Within  a  system  mission, 

system  functions  and  their  corresponding  performance  objectives 
will  have  been  identified  from  data  sources  described  earlier. 
For  each  performance  objective,  the  conditions  under  which 
performance  occurs  will  vary  (e.g.,  day  vs.  night  operation) 
and  may  alter  performance  criteria.  Thus,  performance 
conditions  for  any  one  objective  will  be  established  as  "cases" 
across  which  analysis  occurs. 
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2.  Use  of  tasks:  System  components  (hardware/software)  which 
support  a  function  and  its  performance  objectives  will  be 
identified  from  the  system  design  data.  Tasks  required  by 
these  components  will  then  be  identified  to  serve  as  the 
"objects"  of  analysis. 

3.  The  above  input  data  will  be  keyed  into  the  computer  hosting 
the  Product  5  tool.  A  user  protocol  will  be  developed  (as  part 
of  a  user  guide)  for  the  raw  data;  a  menu-driven  approach  will 
be  built  into  the  program  to  aid  input  procedure  and  data 
editing. 

4.  Tasks  will  be  classified  by  the  user  as  to  which  system 
performance  objective  they  support  or  belong  to.  If  the 
performance  objective  could  be  expected  to  be  performed  under 
various  field  conditions,  the  performance  objective  will  be 
represented  several  times  in  the  matrix  (for  each  condition) 
and  the  tasks  classified  on  each.  No  subject-matter-experts 
will  be  needed  to  make  the  task  classifications. 

5.  Hierarchical  cluster  analysis  (or  variant)  will  be  applied  to  a 
"task"  X  "performance  objective"  data  matrix  to  analyze  the 
data  and  identify  task  clusters. 

•  Outputs  and  Use  of  Cluster  Analysis 

1.  Hierarchical  cluster  tree  (taxonomy)  of  system  tasks  will  be 
derived  to  show  the  operational  relationship  of  all  tasks  (both 
operator  and  maintainer)  and  relation  of  these  to  system 
mission,  function,  and  associated  performance  objectives. 

2.  The  next  analysis  performed  by  Product  5  (description  to  follow 
this  one)  will  partition  the  derived  task  clusters  into  jobs/ 
personnel  required  to  determine  crew  size. 

User  Inputs  to  the  Task  Clustering  Matrix.  The  user  makes  three  inputs 
to  the  task  clustering  matrix:  rows  of  system  performance  objectives, 
columns  of  tasks,  and  a  determination  for  matrix  cells  (only  those  that  are 
not  automatically  entered  by  the  system)  indicating  a  positive  relationship 
between  a  performance  objective  and  tasks. 

Prior  to  effecting  the  task  clustering,  three  levels  of  information 
(mission,  function,  and  task)  will  be  available  for  input  into  the  tool  by 
the  Product  5  user.  The  sources  of  these  data  were  discussed  earlier. 

Of  these,  only  two  inputs  will  be  required  for  Analysis  I  (the  cluster 
analysis):  performance  objectives  and  task  list.  These  inputs  serve  as  the 
"cases"  and  "objects"  of  analysis,  respectively.  Task  clustering  requires 
the  creation  of  a  "performance  objectives"  by  "tasks"  matrix. 

As  described  earlier,  the  system  will  impose  a  macro-structure  on  data 
entry  by  using  templates  developed  from  the  Kaplan  and  Crooks  (1980) 
taxonomy.  Use  of  the  Kaplan  and  Crooks  templates  will  assure  that  all 
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system  performance  objectives  and  tasks  can  be  accounted  for  even  in  the 
early  stage  of  system  design. 

The  user  will  enter  data  into  the  matrix  by  entering  one  row  (system 
performance  objective)  and  its  associated  columns  (tasks),  then  progress  to 
the  next  row  and  its  columns.  The  system  will  begin  the  data  entry  process 
by  prompting  the  user  to  specify  system  component  mission.  The  system  will 
provide  a  data  source  for  this  item.  If  the  user  does  not  have  the 
information,  the  system  missions  from  the  Kaplan  and  Crooks  taxonomy  will  be 
presented,  and  the  user  will  select  one  of  those.  An  example  of  a  system 
would  be  "aviation  system,"  an  example  of  a  system  component  would  be 
"pilot-operated  defense  system,"  and  an  example  of  a  system  component 
mission  would  be  "destroy  enemy  vehicles." 

Next,  the  system  will  prompt  the  user  to  enter  the  first  system 
performance  objective.  As  will  be  thoroughly  described  in  the  section  on 
forming  unique  jobs,  performance  objectives  refer  to  a  time  constraint, 
output  requirement,  or  continuous  activity.  The  user  will  be  prompted  to 
provide  three  pieces  of  information  for  each  system  performance  objective: 
the  goal,  conditions  of  performance,  and  criterion  of  performance.  An 
example  of  system  performance  objective  goal  would  be  "to  defend  the 
aviation  system  against  enemy  fire  causing  the  enemy  to  retreat  or  be 
destroyed."  An  example  of  a  performance  condition  would  be  "in  the  air,  in 
the  presence  of  an  aggressing  air  vehicle,  during  the  day."  An  example  of  a 
criterion  of  performance  would  be  "enemy  retreats  or  is  destroyed  without 
loss  of  life  or  property  to  our  force."  With  data  entered,  the  user  stores 
(by  pressing  a  function  key)  the  system  performance  objective,  named 
Objective  1.0  by  the  system  or  something  more  descriptive  by  the  user.  Any 
change  in  performance  condition  of  performance  criterion  becomes  part  of 
another  system  performance  condition. 

The  user  will  able  to  enter  free  text  system  performance  objectives. 
However,  invocation  of  the  system  "help"  function  will  produce  a  menu  of 
options  for  each  part  of  the  system  performance  objective.  These  options 
will  be  derived  again  from  the  Kaplan  and  Crooks  taxonomy. 

Once  Objective  1.0  is  stored,  the  user  will  be  prompted  to  enter  the 
tasks  associated  with  accomplishment  of  that  objective,  and  data  sources 
will  be  provided.  The  user  enters  each  task  in  free  text.  (The  system  will 
prompt  the  user  to  enter  these  tasks  in  sequence.  Task  times  will  be 
entered  at  this  time  as  well  if  the  user  desires.)  If  the  user  does  not 
have  the  information,  the  user  can  press  a  function  key  and  produce  menus 
based  on  the  Kaplan  and  Crooks  taxonomy  from  which  to  select  tasks.  When 
all  tasks  for  the  given  objective  are  entered,  the  user  presses  a  function 
key  to  save  the  data.  Then  the  system  prompts  for  the  next  system 
performance  objective  and  its  associated  tasks. 

With  information  on  "tasks"  and  "performance  objectives"  entered,  the 
two  dimensions  of  the  input  data  matrix  will  be  established.  Figure  6  shows 
the  dimensions  of  the  data  matrix  constructed  at  this  point  from  input  data. 
The  relationship  between  the  two  dimensions  for  the  data  matrix  shown  in 
Figure  6  is  logical.  All  parameters  of  the  system  are  accounted  for  by  the 
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System  Function 


Tasks  for  System  Component (s) 


KEY:  SC  =  System  Component  (i.e.,  hardware/software)  associated  with 
system  function. 

T  =  Task  associated  with  a  system  component  (e.g.,  a  task  could  be 
load,  aim,  or  fire  weapon). 

PO  =  Performance  Objective  that  supports  a  system  function. 

C  =  Relevant  Condition  under  which  performance  occurs,  e.g.,  day, 
night,  target  moving,  target  stationary. 

0  =  Task  does  not  pertain  to  the  PO. 

1  =  Task  pertains  to  the  PO. 


Figure  6.  Matrix  for  Creating  Task  Clusters. 
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dimensions.  If  the  system  is  large,  the  user  will  enter  performance 
objectives  for  one  component,  then  move  to  another  component. 

Entering  data  into  the  cells  is  the  next  step.  It  must  be  determined 
which  of  all  the  tasks  listed  in  the  matrix  columns  relate  to  each  system 
performance  objective.  Simply,  the  tasks  will  be  classified  as  to  which 
performance  objective  the  tasks  apply  (a  matter  already  known  from  the 
initial  system  design  inputs).  Dichotomous  scoring  (i.e.,  1  =  if  pertaining 
to  the  performance  objective,  0  -  if  not)  will  be  used  to  classify  each  task 
and  thus  provide  all  tasks  with  a  cell  entry.  The  cells  will  be  filled  in 
one  of  two  ways.  First,  the  system  will  automatically  enter  a  "1"  for  each 
task  that  was  entered  following  the  entry  of  a  performance  objective. 

Second,  for  those  cells  not  filled  automatically,  the  user  will  be  taken 
to  each  cell  and  asked  to  determine  task-system  performance  objective 
relationships.  Once  the  cells  of  the  matrix  are  filled,  hierarchical 
clustering  of  the  matrix  can  be  accomplished  to  define  task 
interrelationships. 

Figure  6  provides  example  cell  entries.  These  have  been  prepared  to 
illustrate  task  clustering  for  two  possible  types  of  clusters.  Tasks  under 
system  component  (SC)  #1  (say  a  mounted  weapon)  fulfill  performance 
objective  (PO)  #1  and  its  four  variations  (performance  conditions).  Tasks 
under  SC  #2  serve  PO  #2.  Obviously,  these  two  distinct  sets  of  tasks  bear 
little  relation  to  one  another  and  will  emerge  in  different  clusters.  On 
the  other  hand,  tasks  under  SC  #3  are  identical  to  those  of  SC  #1  and 
likewise  serve  PO  #1.  Why?  Presumably,  it  is  a  second  mounted  weapon 
located  apart  from  SC  #1  and  suggests  that  a  second  weapon  operator  will  be 
required.  The  point  to  be  made  is  that  such  a  duplication  will  not  be  lost 
in  the  data  matrix  nor  in  the  output  --  two  mounted  weapon  operations  will 
emerge  in  a  single  cluster  while  the  tasks  associated  with  SC  #2  will,  as 
stated  before,  emerge  as  its  own  separate  cluster. 

At  this  point  in  the  process,  the  user  can  obtain  a  printout  of  the 
matrix  to  review.  Revisions  to  the  matrix  can  thus  be  made  before  the 
cluster  analysis  process  is  undertaken  by  the  system. 

The  Cluster  Analysis  Process.  Hierarchical  cluster  analysis  is  the 
analytic  design  of  choice  for  rendering  the  "tasks"  X  "performance 
objectives"  matrix  into  a  taxonomy  of  task  relationships  (task  analysis). 
There  are  a  number  of  reasons  for  selecting  clustering,  and  this  particular 
design,  for  the  present  analysis.  Though  hierarchical  clustering  is  perhaps 
the  best  known  and  more  used  method  of  late,  there  are  many  approaches  to 
clustering.  Some  employ  conventional  clustering  procedures;  others  rely 
upon  factor  analytic  techniques  (Guertin,  1971).  Still  others,  such  as  the 
SAS  "VARCLUS"  method  combine  elements  of  both  cluster  and  factor.  Some 
excellent  reviews  of  the  range  of  methods  are  found  in  Lorr  (1983)  and 
Thorndike  (1978). 

One  important  difference  between  cluster  and  factor  methods  is  that  in 
cluster  methods  a  variable  is  assigned  to  only  one  cluster  --  whereas  factor 
analysis  breaks  up  the  variance  of  a  variable  into  several  additive  parts. 
Thus,  cluster  is  the  design  of  choice  when  one  wishes  to  build  something  up 
from  individual  elements  (synthesis)  as  is  the  case  where  tasks  must  be 
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aggregated  into  related  of  activities  for  operators  and  maintainers.  The 
critical  statistic  employed  to  effect  the  design  is  Euclidean  distance 
between  the  variables  (tasks).  Essentially,  the  mean  distance  among 
variables  within  a  cluster  is  compared  to  the  mean  distance  between  all 
variables  in  the  analysis  as  variables  are  successively  compared  to  leading 
and  later  clusters  for  membership.  The  output  is  a  hierarchical  cluster 
tree  and  metrics  of  association  among  variables;  numerous  other  supplemental 
statistics  are  also  provided. 

For  the  proposed  analysis,  the  tree  would  reflect  all  tasks  ordered 
into  operations  ( i . e . ,  their  functional  relationships)  amenable  to  later 
subdivision  into  work  stations  (jobs)  and,  thus,  crew  size.  An  illustration 
of  the  prospective  result  is  shown  in  Figure  7,  although  this  type  output 
from  Product  5  will  be  much  more  easy  to  read  than  the  sample.  To  effect 
the  cluster  analysis,  which  tasks  to  enter  into  the  analysis  at  any  one  time 
must  be  a  consideration.  The  system  of  interest  may  simply  be  too  large 
(too  may  tasks)  to  conduct  an  analysis  which  involves  all  system  operations. 
Further,  the  user  may  not  have  all  system  data  available;  the  data  will 
likely  evolve  in  "chunks"  and  part-system  analysis  may  be  of  interest.  The 
solution  is  to  select  system  components  as  the  basis  for  which  tasks  are 
included  in  analysis.  In  other  words,  the  user  will  conduct  multiple 
analyses  of  the  system  --  component  by  component.  Results  of  the  component 
analyses  can  be  integrated  for  the  total  system  through  second  order 
clustering  to  join  components. 

Clustering  Problems.  Historically,  two  problems  have  stirred 
controversy  as  regards  the  use  of  cluster  analysis.  The  first  concerns  the 
selection  of  algorithms  for  joining  clusters.  In  recent  times,  clustering 
has  become  more  accepted,  and  this  concern  has  lessened  due  to  the  proven 
robustness  of  cluster  solutions  and  widespread  acceptance  of  mediating 
algorithms  such  as  those  by  Hartigan  (1975)  and  Johnson  (1967)  which  are  in 
use  with  notable  statistical  packages  such  as  SAS  and  BMD.  Additionally, 
selection  of  a  distance  algorithm  is  trivial  in  the  present  case  due  to  the 
intentional  use  of  "1"  and  "0"  as  the  coding  scheme,  which  reduces  all 
distance  measures  to  a  singular  and  highly  reliable  range  (unitary  measure). 
The  effectiveness  of  this  approach  has  been  demonstrated  in  a  similar 
context  by  Kraemer,  Boldovici,  and  Boycan  (1975)  and  Wheaton,  Fingerman,  and 
Boycan  (1978).  The  latter  study  produced  a  clustering  algorithm  for  the 
Army  Research  Institute.  The  algorithm  is  in  the  spirit  of  Hartigan' s 
approach  and  delineates  the  steps  through  which  clustering.  A  copy  is 
provided  in  Appendix  J.  The  clustering  algorithm  for  the  present  concept  is 
expected  to  be  similar.  It  will  be  beneficial  to  ARI  to  possess  its  own 
variation  on  this  model  and  thus  be  free  of  use  constraints  imposed  by 
proprietary  software. 

The  second  problem  concerns  criteria  for  optimal  clusters  --  a  problem 
shared  by  factor  analysts  when  attempting  to  determine  the  minimal  number  of 
factors  that  will  optimize  the  accounting  of  variance  in  a  factor  solution. 
In-depth  discussion  of  this  problem  and  its  solutions  can  be  found  in 
reviews  of  clustering  techniques  by  Anderberg  (1973),  Everitt  (1947)  and 
Friedman  and  Rubin  (1967).  Unfortunately,  cluster  analysis  is  a  poor  cousin 
to  factor  analysis  regarding  availability  of  optimal -cl uster  estimation 
methods.  However,  Kendall  (1980)  points  out  that  cluster  solutions  fall 
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Clustered  Functionally  to  Define  08M  Activities 


into  two  categories:  those  where  clusters  are  correlated  and  those  where 
they  are  not.  In  the  former  case  ^correlated,  as  it  is  expected  that  many 
of  the  system  tasks  will  be),  Kendall  demonstrates  that  the  number  of 
clusters  should  be  equal  to  the  number  of  factors  derived  for  the  same  data 
set  in  a  factor  analysis.  Fortunately,  factor  estimation  criteria  (while 
not  perfect)  are  richer  in  number  and  mathematical  soundness  than  those  for 
selecting  optimal  number  of  clusters  (e.g.,  Cattell's  scree  test,  the 
Joreskog  model,  Kaiser's  default  criterion,  Fisher's  test  for  the 
significance  of  factors;  see  Child,  1970,  Kendall,  1980,  and  Joreskog, 

1971).  A  number  of  these  are  in  wide  use  with  major  statistical  packages, 
and  all  can  be  programmed  for  automated  determination.  As  it  seems 
infeasible  that  for  a  single  system  or  system  component  all  tasks  would  be 
discretely  independent  (no  inter-correlation),  then  one  or  more  of  the 
factor  criteria  for  selecting  the  optimal  number  of  clusters  could  be 
incorporated  into  the  PC-AT  program. 

PC-Based  Clustering.  A  final  consideration  is  how  to  effect  the 
hierarchical  clustering  routine  on  a  stand-alone  PC-AT  type  computer?  The 
major  limitation  here  is  random  access  memory  (RAM)  limitations  assumed  by 
commercially  available  cluster  routines  for  PCs.  (For  example,  one  of  the 
better  programs  available  from  Spring-Stat  Statistics  restricts  the  PC 
cluster  program  to  a  20  x  40  matrix.)  Given  this  commonplace  inavailabil ity 
of  programs  to  do  the  job,  it  is  assumed  that  a  tailor  made  software  program 
must  be  developed  for  this  product. 

Even  with  a  uniquely  designed  program  and  a  gigabyte  or  extended 
memory,  the  PC  might  still  experience  memory  (workspace)  limitations  that 
preclude  analyzing  all  components  of  a  complex  system  design  at  once.  Cluster 
analysis  will  have  to  address  one  or  a  few  components  of  the  subject  system 
at  a  time.  How,  then,  will  these  be  merged  together  to  achieve  a  total 
system  analysis.  Just  as  a  factor  intercorrelation  matrix  can  be  second  and 
third  order  factored  and  so  on  to  reveal  a  hierarchy  of  constructs 
underlying  a  set  of  related  factors,  so  can  the  cluster  analyses  of 
individual  system  components  be  later  joined  into  a  comprehensive  scheme. 

For  example,  the  outcome  of  the  example  data  matrix  given  in  Figure  6  is 
shown  above  a  bracket  in  Figure  7.  The  use  of  intercluster  association 
metrics  permits  the  smaller  solution  to  be  merged  with  other  small  solutions 
into  a  whole  via  higher  order  clustering  of  the  metrics.  This  procedure  can 
be  programmed  into  the  PC  clustering  routine. 

Output  of  Clustering.  The  terminal  output  of  the  system-task  taxonomy 
analysis  was  illustrated  in  Figure  7.  There,  all  system  missions, 
functions,  and  tasks  associated  with  system  components  and  performance 
objectives  are  accounted  for  in  terms  of  operations  or  maintenance  clusters. 
The  figure  obviously  illustrates  an  entire  system  accounting.  For  a  very 
small  system  this  may  be  possible  as  a  single  analysis  on  the  PC-AT.  More 
likely,  though,  the  process  will  be  iterative  --  accounting  for  the  system 
by  analyzing  only  one  or  a  few  components  at  a  time,  filing  that  result,  and 
continuing  until  all  components  have  finally  been  accounted  for. 

Cluster  analysis  output  represents  a  significant  step  forward  toward 
achieving  the  goal  of  Product  5.  Early  source  data  were  transformed 
objectively  to  a  more  manageable  and  reliable  data  set  for  further 
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manipulation.  The  output  data  set  will  include  not  only  the  hierarchical 
cluster  tree,  but  also  strength-of-association  metrics  and  numerous  optional 
statistics  such  as  scale  scores.  (The  printout  will  be  designed  for  ease  of 
use,  and  it  will  not  intimidate  the  non-statistician.)  The  present  output 
reports  the  functional  interrelationship  of  all  system  tasks  and  can  now  be 
reduced  to  prospective  operator  or  maintainer  job  assignments  (estimation  of 
crew  size).  This  can  be  accomplished  in  either  the  predictive  mode 
(determine  minimal,  adequate  crew  given  the  system  design)  or  in  the 
prescriptive  mode  (validate,  from  system  characteristics,  a  predetermined 
crew  size) . 

The  next  section  describes  the  techniques  to  be  employed  to  derive 
operator  and  maintainer  jobs  from  the  objectively  clustered  tasks. 


Analysis  II:  Converting  Task  Clusters  Into  Unique  Jobs 

General .  The  number  of  jobs  required  to  operate  and  maintain  a  weapon 
system  depends  largely  on  the  functions  that  must  be  performed  and  the 
sequence  and  timing  of  the  requirement  for  these  functions.  The  previous 
section  described  the  methods  for  clustering  tasks  into  clusters  such  that 
the  tasks  within  a  cluster  relate  to  similar  performance  objectives.  In 
this  section,  an  approach  for  partitioning  the  tasks  within  each  cluster 
into  specific  jobs  is  described.  Consistent  with  the  clustering  step,  the 
approach  for  partitioning  clusters  into  jobs  is  amenable  to  automation  in  a 
microcomputer  environment.  Both  operator  and  maintainer  jobs  are 
considered.  Three  inputs  are  required:  (1)  The  functionally  aggregated 
tasks  output  from  Analysis  I,  (2)  task  sequence,  and  (3)  task  times  (see 
Figure  2).  These  data  and  their  entry  were  previously  described. 

Categories  of  Task  Clusters.  The  operator  and  maintainer  task  clusters 
will  be  classified  into  one  of  three  categories  based  on  the  nature  of  the 
performance  objective  with  which  they  are  associated.  Although  tasks  in 
different  clusters  may  be  similar  in  nature,  jobs  created  from  the  different 
clusters  will  differ  substantially  in  terms  of  how  the  jobs  are  derived. 
These  task  cluster  categories  are  defined  as  follows: 

•  Category  1:  Time-based,  mission-oriented  operator/f ield  personnel 
tasks.  Category  1  tasks  are  those  that  must  be  completed  within  a 
specified  time  period,  i.e.,  a  response  time.  These  tasks  are 
associated  with  performance  objectives  that  include  mission 
timelines.  While  the  tasks  in  this  category  are  not  performed 
constantly,  they  must  be  performed  within  a  specified  amount  of 
time  once  a  order  to  begin  is  received.  The  response  time 
requirement  is  relatively  independent  of  the  number  of  times  the 
task  must  be  performed.  Examples  of  such  tasks  include  the  tasks 
required  to  execute  a  fire  mission  aboard  a  self-propelled  howitzer 
or  the  time  within  which  a  repair  team  effect  a  specific  field 
repair  task.  These  tasks  tend  to  be  mission-oriented  operator 
tasks  or  task  executed  by  personnel  in  the  field. 

•  Category  2:  Output-based,  maintainer  tasks.  The  second  task 
category  consists  of  those  tasks  that  are  performed  continuously 
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over  time  and  result  in  the  production  of  some  countable  output 
{e.g.,  parts  replaced  or  repaired).  The  performance  objective  for 
these  tasks  may  include  some  production  level  requirement.  Tasks 
in  this  category  are  more  easily  anticipated  and,  therefore,  the 
workload  can  be  arranged  such  that  a  relatively  constant  flow  of 
work  is  maintained  and  the  workload  can  be  balanced  among  the  jobs. 
These  are  most  likely  to  be  maintainer  tasks  that  take  place  at  the 
intermediate  or  lower  levels. 

•  Category  3:  Coanitive/monitorina  tasks.  The  third  category  of 
tasks  includes  those  tasks  that  are  performed  constantly  and  not 
measured  in  terms  of  number  of  units  of  output  produced  (e.g.,  fire 
missions,  rounds  of  ammunition,  remove  and  replace  actions)  but 
rather  in  terms  of  the  period  of  time  during  which  the  task  must  be 
performed.  The  performance  objectives  associated  with  these  tasks 
are  more  likely  to  be  cognitive  in  nature.  Examples  include 
surveillance  or  security  activities  and  equipment  or  situation 
monitoring.  These  are  operator  tasks. 

The  nature  of  tasks  in  each  of  the  categories  dictates  that  they  be 
treated  differently  when  determining  the  number  of  jobs  required  to  perform 
the  tasks  in  a  manner  that  meets  mission  and  support  requirements.  Note 
that  while  accuracy  requirements  must  clearly  be  associated  with  the 
performance  objectives  of  tasks  in  all  three  categories,  the  way  jobs  are 
created  is  largely  determined  by  how  much  time  is  available  for 
accomplishing  each  task.  In  Category  1,  jobs  must  be  assigned  such  that 
response  times  are  met  with  secondary  consideration  given  to  how  well 
balanced  the  tasks  are  among  the  crew.  Tasks  in  Category  2  should  be 
assigned  to  jobs  such  that  the  workload  is  reasonably  balanced  while  meeting 
the  "production"  requirement.  Note  that  while  tasks  may  be  assigned  to  jobs 
in  a  number  of  ways  in  order  to  meet  the  production  requirement,  the  purpose 
for  balancing  the  workload  among  jobs  is  to  minimize  the  variance  in  idle 
time  among  the  jobs  so  that  the  work  can  be  performed  as  efficiently  as 
possible.  Category  3  tasks  generally  dictate  the  number  of  jobs  required 
based  on  their  location  and/or  area  of  responsibility  rather  than  on  the 
time  required  to  perform  specific  tasks.  Consequently,  the  approach  to 
assigning  these  tasks  to  jobs  is  much  simpler  than  that  required  for  tasks 
in  the  first  two  categories. 

The  tasks  in  each  task  cluster  will  be  partitioned  into  unique  jobs 
using  generally  accepted  industrial  engineering  and  operations  research 
techniques  for  structuring,  measuring,  and  organizing  work.  The  method  used 
to  determine  jobs  using  tasks  in  Categories  1  and  2  described  above  employs 
"network  analysis"  techniques.  The  tasks  in  Category  3  are  overlaid  onto 
jobs  in  the  first  and  second  category  subject  to  limitations  due  to 
proximity  and  available  time.  Figure  8  shows  graphically  the  process  to  be 
used  for  converting  the  tasks  in  each  cluster  into  unique  jobs.  A  more 
detailed  graphic  will  be  presented  for  each  task  category,  later  in  this 
section. 

Forming  Jobs  From  Category  1  Tasks.  The  process  for  forming  jobs  from 
Category  1  task  clusters  is  drawn  largely  from  the  production  scheduling  and 
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Figure  8.  Process  for  Converting  Task  Clusters  Into  Jobs. 


resource  planning  literature.  Figure  9  shows  the  process  of  creating  these 
jobs.  The  steps  are  listed  below. 

1.  Determine  the  technological  sequence  of  tasks  required  to  perform 
each  function.  (User  may  update  original  entered  sequence.) 

2.  Develop  a  precedence  network  defining  the  task  relationships  to  the 
required  functions. 

3.  Determine  the  time  required  to  perform  each  task  under  each  set  of 
environmental  conditions.  (Input  earlier,  user  may  update.) 

4.  Identify  required  response  time  for  the  job  function  and  check  task 
times  against  response  time  requirement.  If  one  or  more  task  times 
exceed  the  response  time,  the  task(s)  must  be  redesigned  or  the 
response  time  must  be  relaxed. 

5.  Identify  constraints  on  assigning  tasks  to  jobs  due  to  proximity 
and  simultaneity  requirements. 

6.  Using  automated  resource  allocation  techniques,  create  work 
stations/jobs  based  on  the  precedence  network  and  response  time 
requirements. 

7.  Test  the  sensitivity  of  the  number  of  work  stations/jobs  to  the 
response  time  requirement. 

8.  List  the  possible  job  assignments  and  resulting  response  times. 

Input  to  Step  1  is  the  task  sequence  entered  by  the  user  during  data 
entry.  Each  task  related  to  a  given  system  function  is  entered  by  the  user 
along  with  its  immediate  predecessor(s)  (i.e.,  the  task(s)  that  must  be 
completed  before  it  can  begin).  Note  that  all  tasks  related  to  a  given 
function  will  fall  in  the  same  task  cluster  since  clusters  are  formed  on  the 
basis  of  performance  objectives.  The  system  design  will  drive  the  task 
sequence.  The  sequence  will  be  determined  by  successively  asking  the 
question  "What  tasks  must  be  completed  before  this  task  can  begin?"  The 
questioning  process  continues  until  all  tasks  related  to  a  function  have 
been  placed  in  sequence  (note  that  some  tasks  or  series  of  tasks  may  be 
performed  in  parallel). 

Step  2  formalizes  the  information  collected  in  the  first  step  by 
creating  a  network  that  reflects  the  aggregate  set  of  precedence 
requirements  associated  with  the  successful  accomplishment  of  a  given 
function.  The  precedence  network  is  important  in  that  it  identifies  those 
tasks  that  must  be  performed  in  sequence  and  those  that  can  (but  not  must) 
be  done  at  the  same  time.  This  is  done  automatically. 

Step  3  assigns  times  to  each  of  the  tasks  in  the  precedence  network. 

The  method  that  Product  5  will  use  to  identify  and  assign  task  times  was 
discussed  earlier.  An  example  of  a  precedence  network  (from  Step  2)  with 
task  times  (from  Step  3)  is  shown  in  Figure  10. 
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In  Step  4,  the  response  time  requirement  for  the  total  job  function  is 
identified  for  the  specific  set  of  tasks  required  to  accomplish  the 
function.  Note  that  the  achievable  response  time  for  a  function  cannot  be 
less  than  the  greatest  sum  of  all  sets  of  required  tasks  that  must  be 
performed  sequentially.  If  the  sum  of  the  task  times  for  a  required  set  of 
sequential  tasks  exceeds  the  required  response  time,  then  the  response  time 
cannot  be  achieved  regardless  of  the  crew  size.  In  this  case,  either  the 
response  time  must  be  relaxed  or  the  system  must  be  redesigned  to  reduce  the 
time  required  to  perform  the  tasks  in  the  sequence. 

Step  5  in  the  job  forming  process  requires  identification  of  any 
constraints  that  might  affect  the  partitioning  of  tasks  into  jobs.  These 
constraints  will  restrict  the  formation  of  jobs  and  may  arise  due  spatial 
considerations  (i.e.,  distance  between  working  areas  in  which  tasks  are 
performed)  or  a  requirement  that  two  or  more  tasks  occur  simultaneously  or 
in  rapid  succession.  Tasks  that  cannot  be  combined  intr  the  same  job  will 
be  tagged  to  ensure  that  they  are  not  combined.  Another  form  of  constraint 
is  one  that  requires  a  set  of  tasks  to  be  performed  by  the  same  person. 
Constraints  of  this  type  may  cause  tasks  from  different  job  clusters  to  be 
combined  in  the  same  job.  The  user  will  be  asked  if  simultaneity  or 
proximity  constrains  job  function.  The  system  default  will  be  "no" 
constraints. 

Step  6  of  the  process  is  at  the  heart  of  the  job  forming  process.  The 
process  makes  use  of  a  network  analysis  technique  know  as  the  critical  path 
method  (CPM)  or  critical  path  scheduling  (CPS).  In  the  case  of  Category  1 
tasks,  the  objective  is  to  determine  the  number  of  jobs  required  to  meet  the 
mission  timeline  requirements  for  completing  all  the  tasks  required  to 
successfully  accomplish  the  function. 

Step  6  is  an  iterative  process  through  which  tasks  are  assigned  to  a 
given  crew  size  such  that  the  response  time  is  minimized.  If  the  minimum 
response  time  achievable  with  a  given  crew  size  is  unacceptable  (i.e.,  it 
fails  to  meet  the  system  requirement),  the  crew  size  will  be  increased. 

This  process  will  continue  until  the  point  where  either  the  requirement  is 
met  or  further  increases  in  crew  size  do  not  decrease  the  response  time. 

This  process  is  repeated  for  each  job  cluster  containing  Category  1  tasks. 

In  each  case,  the  minimum  number  of  jobs  that  can  still  meet  the  required 
response  times  is  determined.  The  largest  of  these  minimum  requirements  is 
the  lower  bound  for  jobs  for  the  weapon  system  for  Category  1  tasks.  If  any 
of  the  functions  must  be  carried  out  simultaneously,  the  number  of  jobs  must 
increase  to  permit  all  of  the  required  tasks  to  be  completed  within  the 
required  time  for  all  functions  that  must  be  completed  together. 

Several  slightly  different  algorithms  are  available  for  implementing 
the  resource  allocation  process  described  above.  Lang  (1977)  provides  a 
heuristic  approach  for  allocating  a  single  type  of  resource  to  tasks  in  a 
critical  path  network.  An  algorithm  for  allocating  multiple  resources  was 
developed  by  Brooks  (1963)  and  further  extended  by  Bedworth  (1973)  and 
Bedworth  and  Bailey  (1982).  Bedworth  and  Bailey  (1982)  provided  a  computer 
coded  algorithm  that  implements  the  Brook's  algorithm. 
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Brook's  (1963)  algorithm  (BAG)  was  selected  for  use  in  Product  5  for 
assigning  Category  1  tasks  to  jobs.  The  computer  coded  algorithm  is 
available  for  use  in  Product  5.  The  steps  required  to  assign  tasks 
(activities)  to  jobs  (resources)  are  as  follows.  For  convenience,  Figure  11 
gives  a  network  and  tabular  results  of  these  steps  based  on  three  jobs. 

A.  Develop  the  task  network,  identifying  tasks  and  their  required 
times. 

B.  Determine  the  maximum  time  each  task  controls  through  the  network 
on  any  one  path.  This  is  like  calculating  the  critical -path  time 
through  the  network  assuming  that  the  starting  node  for  each  task 
being  analyzed  is  the  network  starting  node.  This  activity  control 
time  will  be  designated  ACTIM  for  convenience. 

C.  Rank  these  times  in  decreasing  ACTIM  sequence,  as  in  Figure  11  (G, 
A,  C,  etc.).  ACTIM  for  task  A  is  found  by  summing  the  times  for 
tasks  A,  D,  and  E,  to  obtain  a  total  of  16.  The  rows  titled  TEARL, 
TSTART,  TFIN,  and  TNOW  are  explained  as  follows: 

1.  TEARL  is  the  earliest  possible  time,  because  of  precedence  and 
time  limitations,  to  schedule  each  task.  The  actual  time  will 
be  equal  to  or  later  than  TEARL.  TEARL  equals  the  latest  TFIN 
time  for  all  immediate  predecessor  tasks. 

2.  TSTART  is  the  actual  start  time  of  the  task.  If  there  were  no 
job  limitations,  TSTART  would  always  equal  TEARL. 

3.  TFIN  is  the  completion  time  of  each  task.  This  equals  the 
tasks  TSTART  added  to  the  job-duration  time. 

4.  TNOW  is  the  time  at  which  job  assignments  are  now  being 
considered.  Initially  TNOW  equals  zero,  but  subsequently  it 
equals  the  lowest  TFIN  time  for  all  tasks  currently  being 
worked  on. 

D.  Sequence  the  tasks  according  to  job  constraints.  TNOW  is  set  at 
zero.  The  allowable  tasks  (ACT.  ALLOW.)  to  be  considered  for 
scheduling  at  TNOW  of  zero  are  those  tasks  that  would  have  a 
critical  path  method  starting  time  of  0,  namely  tasks  G,  A,  and  C. 
These  are  placed  in  the  ACT.  ALLOW,  row,  sequenced  in  decreasing 
ACTIM  order.  In  this  example,  G,  A,  and  C  all  have  the  same  ACTIM, 
and  so  a  secondary  rule  is  needed.  For  this  example  we  will  choose 
longest  duration  first,  which  dictates  schedule  G  first.  Another 
rule  is  needed  for  A  and  C,  since  both  are  five  time-units  long. 
Arbitrarily  choose  A  before  C.  In  the  job-available  column,  the 
jobs  initially  available  are  placed--namely,  three. 

E.  Determine  if  the  first  task  in  ACT.  ALLOW.,  G,  can  be  assigned.  It 
can,  since  three  jobs  are  available  and  G  requires  only  one.  Also, 
no  predecessor  limitations  prevent  G  from  beginning.  G  is  removed 
from  the  ACT.  ALLOW,  list  and  the  number  of  jobs  available  is 
decreased  by  one  to  a  value  of  two,  since  G  required  one  job. 
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Figure  11.  Brooks  Algorithm  Applied  to  Allocation  of  Category  1  Tasks  to 
Multiple  Jobs. 
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TSTART  for  task  G  is  set  at  the  current  TNOW  and  the  TFIN  is  set  a 
TSTART  plus  task  G's  duration  time.  Now  it  is  necessary  to 
determine  if  task  G  being  completed  will  allow  another  task  to  be 
feasible  at  some  future  time.  With  G  it  is  not,  since  G  is  itself 
an  entire  critical  path.  This  same  process  is  repeated  for  the 
remainder  of  ACT.  ALLOW,  tasks  until  the  jobs  available  are 
depleted.  In  this  case,  all  task  G,  A,  and  C  could  be  assigned  a 
TSTART  of  zero.  From  the  network  of  Figure  11  it  is  seen  that 
assigning  task  A  allows  task  B  to  be  scheduled  a  TEARL  of  five 
time-units  later  (task  A's  TFIN).  Similarly,  tasks  D  and  F  can  be 
assigned  a  TEARL  that  is  the  latest  of  A's  and  C's  TFIN  times. 

Note  that  if  task  A  had  required  too  many  resources  to  allow 
assignment  at  TNOW  of  zero,  we  would  still  see  if  task  C  could  be 
assigned. 

F.  TNOW  is  raised  to  the  next  TFIN  time,  which  happens  to  be  five,  the 
completion  times  of  both  tasks  A  and  C.  The  jobs  available  at  TNOW 
of  five  is  set  to  the  number  remaining  after  assigning  resources  at 
TNOW  equal  to  zero  (zero  in  this  case),  added  to  the  number  of  jobs 
freed  because  of  task  co»pletion  at  the  new  TNOW  (two  in  this 
case).  ACT.  ALLOW,  we  now  set  at  those  not  assigned  at  the 
previous  TNOW  (none  in  this  case),  added  to  those  that  have  a  TEARL 
equal  to  or  less  than  TNOW  (D,  B,  and  F). 

G.  Repeat  this  assignment  process  until  all  tasks  have  been  scheduled. 
The  latest  TFIN  gives  the  response  time  that  can  be  achieved  with 
the  resources  assigned--in  this  case,  17  time  units.  Three  jobs 
have  been  scheduled. 

Step  7  in  the  job  forming  process  provides  a  means  for  investigating 
alternative  numbers  of  jobs  and  assessing  the  effect  of  these  alternatives 
on  the  ability  of  the  system  to  meet  performance  requirements.  For  example, 
a  slight  relaxation  in  the  performance  requirement  might  result  in  a  need 
for  one  less  job.  Conversely,  by  adding  another  job  to  a  weapon  system, 
system  performance  may  increase  dramatically.  Systems  designers  and  Army 
decision  makers  need  to  be  aware  of  such  swings  in  both  requirements  and 
performance  in  order  to  make  rational  design  decision. 

The  product  of  this  process  will  be  a  listing  of  the  unique  jobs  that 
result  from  Category  1  tasks.  With  each  job  will  be  a  listing  of  the 
specific  tasks  associated  with  the  job.  Also,  for  each  function  consisting 
of  Category  1  tasks,  a  resource  profile  will  be  shown  that  indicates  what 
each  job  is  required  to  do,  over  what  time  period,  and  the  proportion  of  the 
soldier's  time  that  is  spent  doing  the  tasks  assigned  to  the  job. 

Forming  Jobs  From  Category  2  Tasks.  Category  2  tasks  are  similar  in 
many  respects  to  Category  1  tasks  except  the  time  requirement  is  based  on  a 
production  output  requirement  rather  than  a  response  time  requirement.  The 
process  for  forming  jobs  from  Category  2  tasks  is  illustrated  in  Figure  12. 
The  steps  are  listed  below: 

Step  1.  (Same  as  for  Category  1).  Place  tasks  in  sequence. 
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Figure  12.  Process  for  Converting  Category  2  Tasks  Clusters  Into  Jobs. 


Step  2. 

Step  3. 
Step  4. 
Step  5. 
Step  6. 
Step  7. 
Step  8. 
Step  9. 
Step  10. 


(Same  as  for  Category  1).  Construct  precedence  network  based 
on  sequence  requirements. 

(Same  as  for  Category  1).  Determine  task  times. 

Compute  cycle  time. 

Compute  number  of  required  production  lines. 

Compute  cycle  time  for  each  production  line. 

Assign  tasks  to  work  stations. 

Balance  tasks  among  work  stations. 

(Same  as  Category  1).  Test  sensitivity  of  work  stations. 
(Same  as  Category  1).  List  jobs  and  task. 


For  Category  1  tasks,  the  objective  was  to  determine  the  minimum  number 
of  jobs  necessary  to  meet  the  response  time  requirements.  Minimizing  the 
number  of  jobs  is  also  an  objective  for  Category  2  tasks.  However,  the 
nature  of  Category  2  tasks  is  substantially  different  from  that  of  Category 
1  tasks.  Category  2  tasks  are  most  likely  to  be  found  in  support  areas 
where  work  can  be  more  easily  planned,  scheluled,  and  controlled.  For 
example,  tasks  that  occur  in  a  maintenance  depot  are  more  easily  planned 
than  those  that  occur  in  a  field  setting.  Workload  can  be  maintained  at  a 
more  constant  level  with  less  need  to  respond  quickly.  Consequently,  the 
objective  in  this  environment,  in  addition  to  minimizing  the  number  of  jobs, 
is  to  assign  tasks  to  jobs  in  a  manner  than  balances  the  workload  among  the 
various  jobs. 


The  approach  used  to  create  jobs  from  tasks  in  job  clusters  containing 
Category  2  tasks  is  similar  to  that  used  for  Category  1  tasks.  Steps  1 
through  3  are  exactly  tne  same  as  that  used  for  Category  1  tasks.  Step  4  is 
where  the  production  requirement  is  converted  into  a  required  cycle  time. 

In  Step  5,  the  production  requirement  will  be  expressed  in  units  of  work  per 
time  period  (e.g.,  assemblies  overhauled  per  year).  Step  6  computes  cycle 
time.  Cycle  time  required  to  achieve  the  production  requirement  depends  on 
the  available  time  (e.g.,  one  shift  five  days  per  week,  24-hours  per  day 
every  day)  and  the  number  of  "lines"  performing  the  tasks.  (A  "line" 
consists  of  all  jobs  necessary  to  perform  tasks  related  to  a  given 
function) . 

The  production  requirement  can  be  achieved  either  by  configuring  the 
jobs  such  that  the  cycle  time  is  sufficiently  short  to  meet  the  requirement 
or  by  staffing  several  lines  with  jobs  configured  such  that  a  somewhat 
longer  cycle  time  is  achieved  on  each  line  but  the  combine  production  rate 
of  all  lines  meets  the  production  requirement.  The  number  of  lines  may  be 
provided  as  a  user  input  or  can  be  computed  from  the  production  requirement 
and  task  times.  Product  5  will  be  designed  to  accommodate  either  approach. 
For  example,  if  four  production  lines  are  to  produce,  inspect,  service  or 
repair  assemblies  at  a  rate  of  1000  per  year  and  the  repair  facility  is 
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scheduled  to  operate  40  hours  per  week,  each  line  must  achieve  a  cycle  time 
of  approximately  eight  hours  (i.e.,  an  assembly  must  come  off  each  line  at  a 
rate  of  one  every  eight  hours).  If  we  assume  the  sum  of  times  for  all  tasks 
required  on  each  line  is  30  hours  and  that  no  tasks  exceeds  eight  hours, 
then  at  least  4  work  stations  (i.e.,  jobs)  are  required  on  each  line. 
However,  the  actual  number  of  jobs  per  line  may  exceed  this  limit  due  to 
precedence  requirements  or  other  constraints.  The  objectives  in 
partitioning  tasks  into  jobs  is  to  assign  tasks  to  jobs  such  that  the 
production  requirement  is  met,  the  number  of  jobs  is  at  the  minimum 
necessary,  and  the  workload  is  reasonably  well  balanced  among  the  jobs.  The 
latter  two  objectives  are  complementary  in  that  as  the  jobs  become  more 
balanced,  the  number  of  jobs  required  is  reduced. 

The  procedure  for  allocating  Category  2  tasks  to  jobs  is  equivalent  to 
line  balancing  procedures  used  in  a  manufacturing  environment.  A  number  of 
automated  approaches  for  line  balancing  are  available  that  can  be  used  in 
either  of  two  ways.  First,  given  the  number  of  jobs  or  work  stations,  the 
algorithms  assign  tasks  to  jobs  such  that  the  production  rate  is  maximized 
(or  the  cycle  time  is  minimized).  Second,  given  a  required  cycle  time, 
tasks  are  assigned  to  jobs  such  that  the  number  of  jobs  is  minimized  and  the 
workload  is  as  well-balanced  as  possible.  Buffa  and  Taubert  (1972)  reviewed 
alternative  means  for  achieving  a  well -balance  assignment  of  tasks  to  jobs. 
One  of  the  earliest  proposed  techniques  for  balancing  workload  is  that 
developed  by  Helgeson  and  Birnie  (1961).  Further  improvements  in  the 
workload  balancing  process  were  developed  by  Mansoor  (1964),  Kilbridge  and 
Wester  (1961),  and  Bedworth  and  Bailey  (1982).  The  Bedworth  and  Bailey 
algorithm  is  available  in  code  and  will  be  used  in  the  product. 

Steps  5  and  6  of  the  process  for  assigning  Category  2  tasks  to  jobs  are 
similar  to  the  allocation  process  used  for  Category  1  tasks.  Alternate 
cycle  times  will  be  evaluated  to  determine  their  effect  on  the  number  of 
jobs  required  and  the  degree  to  which  workload  can  be  balanced  among  the 
jobs.  The  process  can  be  described  in  the  following  steps: 

A.  Develop  the  precedence  network  in  the  same  manner  as  for  Category  1 
tasks. 

B.  Assign  precedence  regions  from  left  to  right.  Redraw  the  network, 
assigning  all  tasks  the  latest  precedence  region  possible;  this 
will  ensure  that  tasks  with  few  dependencies  will  at  least  be 
considered  for  assignment  late  in  the  schedule.  Figure  13 
illustrates  how  precedence  regions  are  formed. 

C.  Within  each  precedence  region  rank  tasks  from  maximum  to  minimum 
duration  times.  This  will  ensure  that  the  largest  task  will  be 
considered  first,  giving  the  chance  for  a  better  combination  of 
smaller  tasks  later.  Assigning  most  of  the  small  tasks  early  is 
one  problem  with  some  solution  techniques. 

D.  Assign  tasks  by  the  following  sequence,  conforming  to  process  zone 
restrictions.  Results  of  task  assignment  are  shown  in  Table  1. 

1.  Leftmost  region  first. 
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Region 


Figure  13.  Precedence  Network  for  Category  2  Tasks  (from  Bedworth 
and  Bailey,  1982). 
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Table  1 


Category  2  Task  Assignments  to  Precedence  Regions 
(from  Bedworth  and  Bailey,  1982)  .  a 


Region  Tasks  (Within  Regions,  Priority 

Is  Left-to-Right) 

I 

1 

II 

3 

111 

4 

IV 

5 

V 

7,6 

VI 

8 

VII 

9 

VIII 

11. 10. 12 

IX 

15 

X 

13,16 

XI 

17, 18.  14.2 

XII 

21,20,  19 
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2.  Within  a  region,  assign  according  to  largest  task  first. 

E.  At  the  end  of  each  station  assignment,  decide  if  the  time 
utilization  is  acceptable.  If  not,  check  all  tasks  whose 
predecessor  relations  have  been  satisfied.  Determine  if  changing 
these  for  any  task(s)  within  the  station  whose  predecessor 
region(s)  are  equal  to  or  earlier  than  the  tasks  being  considered 
for  entry  into  the  station,  will  increase  the  utilization.  If  yes, 
make  the  change.  This  station  assignment  is  now  final. 

Table  2  gives  the  solutions  for  the  example  network  shown  in  Figure  13 
such  that  the  workload  is  evenly  balanced  among  five  work  stations  (jobs) 
and  the  cycle  time  achieved  is  21  time  units.  This  algorithm  has  been 
automated  and  will  be  included  as  part  of  Product  5. 

Steps  9  and  10  in  the  job  forming  process  for  Category  2  tasks  are 
identical  to  that  used  for  Category  1  tasks.  It  provides  a  means  for 
investigating  alternative  numbers  of  jobs  and  assessing  the  effect  of  these 
alternatives  on  the  ability  of  the  system  to  meet  production  requirements. 

An  increase  in  the  cycle  time  required  (i.e.,  reduced  production 
requirement)  might  result  in  a  need  for  one  less  job.  Conversely,  by  adding 
another  job,  the  cycle  time  may  decrease  dramatically.  Again,  systems 
designers  and  Army  decision  makers  need  to  be  aware  of  such  swings  in  both 
requirements  and  performance  in  order  to  make  rational  design  decision. 

The  product  of  this  process  will  be  a  listing  of  the  unique  jobs  that 
result  from  Category  2  tasks.  With  each  job  will  be  a  listing  of  the 
specific  tasks  associated  with  the  job.  Also,  for  each  function  consisting 
of  Category  2  tasks,  a  resource  profile  will  be  shown  that  indicates  what 
each  job  is  required  to  do,  over  what  time  period,  and  the  proportion  of  the 
soldier's  time  that  is  spent  doing  the  tasks  assigned  to  the  job. 

Forming  Jobs  From  Category  3  Tasks.  Category  3  task  clusters  are 
unique  in  that  the  "product"  is  not  measured  in  terms  of  units  produced. 
These  tasks  are  those  that  are  implicit  in  the  weapon  system  design  or 
support  requirements  and  are  established  more  by  decree  than  by  measurement. 
For  example,  the  times  associated  with  monitoring  or  security  tasks  are 
seldom  based  on  the  time  required  to  perform  certain  activities.  Rather, 
these  times  are  more  likely  to  be  assigned  based  on  location  and  coverage 
requirements.  Consequently,  these  tasks  must  be  assigned  to  jobs  based  on 
how  well  they  can  be  integrated  with  jobs  containing  Category  1  or  2  tasks. 
The  process  for  determining  the  number  of  jobs  associated  with  Category  3 
tasks  is  illustrated  in  Figure  14.  The  steps  are  listed  below: 

Step  1:  Specify  conditions  under  which  job  must  be  performed. 

Step  2.  Specify  when  job  must  be  accomplished. 

Step  3.  Specify  location  of  job  activities. 

Step  4.  Determine  if  all  tasks  can  be  performed  by  a  single  person. 

Step  5.  Determine  if  tasks  can  be  combined  with  another  job. 
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Table  2 

Assignment  of  Category  2  Tasks/Precedence  Regions  to  Jobs  (Workstations) 
(from  Bedworth  and  Bailey,  1982) 


Station 


Tasks  (in  order  of  assignment) 


1,3.4.  2  [Station  time  -  21] 

3.7.6  [Station  time  *  21] 

8,9,  II,  lo.y*;;*  13 

(12  and  14  originally  assigned  for  a  station  time 
of  20.  Task  13  has  predecessor  assigned  (9)  and 
so  was  interchanged  with  12  and  14  to  give  a 
station  time  of  21] 

12. 1?.  16. 18,><>9.21 

(Original  Assignment  did  not  include  21  (station 
time  of  19):  21  was  interchanged  with  14  and  19 
to  give  a  station  time  of  21] 

14.17.19,20  [Station  time  =  21] 
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Figure  14.  Process  for  Converting  Category  3  Task  Clusters  Into  Jobs. 


Step  6.  Determine  if  tasks  can  be  combined  with  another  job  in  the 
same  job  location. 

If  a  Category  3  task  is  essentially  a  full  time  commitment,  it 
constitutes  an  entire  job.  If  it  is  a  task  that  can  be  performed  "as  time 
permits,"  it  may  be  easily  combined  with  another  job  that  requires  less  than 
all  of  an  operator's  or  maintainer's  time.  Obviously,  Category  3  tasks  can 
only  be  added  to  another  job  if  they  do  not  conflict  with  other  tasks 
already  assigned  to  the  job.  For  example,  piloting  an  aircraft  is  a 
Category  3  task  because  it  is  largely  a  monitoring  and  reacting  task  with  a 
duration  dependent  on  the  distance  traveled  and  the  conditions  experienced 
during  the  course  of  the  flight.  Other  tasks  (e.g.,  navigation,  targeting) 
may  be  combined  with  the  piloting  task  to  the  extent  that  they  do  not 
degrade  or  interfere  with  piloting  responsibilities.  An  aircraft  design 
will  significantly  affect  the  ability  of  the  pilot  to  perform  these 
additional  tasks.  If  the  piloting  task  consumes  essentially  all  of  the 
pilot's  attention,  other  tasks  that  must  be  accomplished  while  the  aircraft 
is  airborne  cannot  be  assigned  to  the  pilot  and,  therefore,  must  be  assigned 
to  a  different  job. 

The  process  for  converting  Category  3  tasks  into  jobs  focuses  primarily 
on  specification  of  the  tasks  that  must  be  performed.  This  activity  is 
shown  as  three  separate  steps  in  Figure  14.  Step  1  is  a  specification  of 
the  conditions  under  which  the  function  must  be  accomplished.  Step  2  is  a 
specification  of  the  time  during  which  the  tasks  are  performed.  Step  3  is  a 
specification  of  where  the  tasks  take  place. 

Steps  4,  5,  and  6  require  user  answers  to  up  to  three  questions 
(defaults  are  provided).  Step  4  asks  if  the  tasks  can  be  performed  within  a 
single  job.  The  user  must  determine  whether  or  not  the  demands  of  the  tasks 
are  such  that  more  than  one  job  is  required  in  order  to  accomplish  them. 

For  example,  if  constant  360-degree  surveillance  of  a  target  area  is 
required,  more  than  one  job  may  be  required  to  provide  the  necessary  level 
of  attention.  Step  5  asks  if  the  tasks  can  be  combined  with  other  jobs. 

Some  Category  3  tasks  may  consume  less  than  100  percent  of  the  operator's  or 
maintainer's  attention  and  can  be  performed  either  simultaneously  or  in 
conjunction  with  Category  1  or  2  tasks.  If  this  is  possible,  the  Step  6 
question  must  be  asked--does  a  job  in  the  same  location  have  adequate 
unscheduled  time  to  permit  combining  Category  3  tasks  with  it.  If  so,  the 
Category  3  tasks  are  overlayed  onto  the  other  jobs  that  will  permit  the 
additional  demands. 

Category  3  tasks  require  the  greatest  amount  of  user  judgment  in 
determining  the  number  of  unique  jobs  required  to  accomplish  them.  However, 
they  are  likely  to  represent  a  relatively  small  portion  of  the  total 
workload  associated  with  the  operation  and  maintenance  of  a  weapon  system 
and  are  most  likely  to  be  associated  with  command,  supervisory,  security, 
and  monitoring  activities. 
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Summary 

The  process  of  converting  job  clusters  into  unique  jobs  is  accomplished 
by  first  cluster-analyzing  the  tasks  to  establish  their  interrelationships, 
then  identifying  the  type  of  tasks  in  each  cluster,  and  applying  several 
widely  accepted  and  commonly  used  techniques  for  assigning  tasks  to  jobs. 
This  process  permits  som*  experimentation  with  alternative  job 
configurations  so  that  tie  impact  of  changes  in  system  requirements  or  crew 
sizes  can  be  addressed.  All  of  the  tools  proposed  can  be  implemented  in  an 
automated  environment  so  the  both  the  time  required  to  assign  tasks  to  jobs 
and  the  user  effort  is  held  to  a  minimum.  The  data  required  to  employ  these 
procedures  is  system  performance  objectives,  tasks,  task  sequence,  and  task 
times.  The  result  of  these  analysis  is  an  objective,  replicable  means  for 
assigning  tasks  to  jobs  so  that  potential  design  shortfalls  can  be 
identified  early  and  corrective  actions  can  be  initiated. 
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USER  TIME  REQUIREMENTS 


The  amount  of  time  it  takes  a  user  to  obtain  an  output  from  Product  5 
is  mostly  dependent  on  the  amount  of  time  it  takes  for  the  user  to  obtain 
and  enter  input  data.  First,  the  user  must  obtain  documentation  with 
information  about  system  performance  objectives,  task  list,  sequence,  and 
times.  Some  users  will  have  obtained  the  needed  documentation  through  the 
normal  course  of  their  jobs.  Other  users  will  have  to  request 
documentation. 

Next  the  user  begins  the  process  of  data  entry.  The  user  will  begin  a 
run  by  entering  identification  data  about  the  system  under  study.  The  user 
will  create  a  new  file  on  the  first  run,  and  will  retrieve  the  file  on 
subsequent  runs.  This  process  will  take  a  minute  or  two. 

The  user  will  be  prompted  to  enter  system  performance  characteristics, 
one  by  one,  as  well  as  their  associated  tasks,  in  sequence,  with  task  times. 
As  mentioned  earlier,  the  user  can  fall  back  on  the  system's  prompts,  help 
function,  and  default  task  time  data  base  to  make  this  job  easy.  The  user 
will  be  able  to  enter  an  exact  performance  objective,  for  example,  or  may 
select  values  from  a  menu.  A  user  with  straightforward  documentation 
covering  only  a  small  number  of  performance  characteristics  may  be  able  to 
enter  this  information  in  less  than  30  minutes.  A  user  entering  data  on 
many  performance  characteristics  may  require  several  hours.  On  subsequent 
runs  involving  the  same  system,  however,  the  user  will  not  have  to  enter 
data  that  have  not  changed,  and  thus,  subsequent  runs  will  be  shorter. 

With  all  input  data  entered,  the  user  can  request  a  printout  of  the 
task  clustering  matrix  and  spend  time  reviewing  it.  This  review  can  be  done 
quickly,  or  could  take  a  day  or  so  if  colleagues  were  consulted.  Next,  the 
user  initiates  the  clustering  process.  The  computer  will  display  a  friendly 
status  message  so  the  user  can  track  system  progress.  The  time  it  takes  the 
computer  to  generate  a  clustering  output  depends  on  the  size  of  the 
performance  characteristics  by  tasks  matrix.  A  matrix  of  50  performance 
characteristics  and  10  tasks  would  be  processed  in  a  matter  of  a  few 
minutes,  given  the  gigabyte  memory  card  and  hard  disk  for  storing  the 
internal  files  produced  by  the  cluster  process.  A  matrix  of  100 
characteristics  and  100  tasks  could  likely  be  processed  in  under  1/2  hour. 
Processing  times  would  be  reduced  if  the  user's  PC  terminal  were  connected 
by  modem  to  a  mainframe,  but  that  is  not  required. 

The  user  will  be  able  to  interrupt  the  process  at  this  point,  but  the 
system  can  be  instructed  to  proceed  straight  to  the  process  of  forming 
unique  jobs.  As  mentioned  earlier,  for  Category  3  task  clusters,  the  user 
will  be  asked  to  answer  three  simple  questions  about  the  tasks  under  study. 
However,  the  Product  can  provide  default  answers  if  needed.  The  job 
formation  process  can  be  expected  to  last  under  1/2  hour,  depending  on  the 
amount  of  data  involved.  While  1/2  hour  may  sound  like  a  long  processing 
time  for  a  PC,  given  the  current  capabilities  of  the  machines,  this  is  well 
within  its  limits. 

How  does  this  projected  user  time  requirement  compare  to  the  time  it 
presently  takes  people  to  generate  manpower  estimates?  Some  people  can 
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provide  manpower  estimates  in  a  matter  of  seconds  by  providing  the  same 
manpower  requirements  of  systems  well  known  to  them.  However,  as  more  and 
more  data  become  available  about  the  new  system,  such  a  quick  method  of 
solution  is  likely  to  produce  erroneous  estimates.  More  thorough  analyses 
of  manpower  estimates  take  about  a  week  using  an  informal  comparability 
approach.  This  is  manual,  unsystematic,  and  provides  no  audit  trail. 

In  summary,  Product  5  can  be  used  quickly  or  the  process  can  take 
several  days  if  the  user  has  to  wait  for  documentation  and  then  wants  to 
enter  in  all  available  data.  In  terms  of  accuracy  of  the  manpower  estimates 
produced.  Product  5  will  produce  reliable  estimates  which  are  derived  from 
the  design  of  the  system  itself.  The  time  spent  in  using  Product  5  will  not 
exceed  the  amount  of  time  spent  on  a  careful  manpower  analysis.  In 
addition,  Product  5  output  will  be  as  accurate  as  possible  given  existing 
documentation,  and  will  allow  for  an  audit  trail. 
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USER  TRAINING 


We  propose  to  build  into  the  software  and  data  bases  of  Product  5  two 
components  that  will  enable  users  to  learn  and  use  the  capabilities  of  the 
product.  The  first  is  a  comprehensive  Embedded  Training  capability.  The 
second  is  a  context-sensitive  Help  and  Explanation  capability.  We 
anticipate  that  the  two  components  will  share  many  data  elements  and 
software  routines,  since  their  purposes  and  functions  are  basically  similar. 


Embedded  Training  Capability 

The  embedded  training  capability  will  be  accessed  from  the  operating 
system  level.  A  unique  command  will  be  provided  to  call  up  and  begin  the 
embedded  training  component,  separate  from  normal  product  functions.  This 
capability  allows  "off-line"  training  to  prepare  new  users  of  the  product  to 
learn  its  functions  and  capabilities,  as  well  as  review  or  sustainment  for 
more  experienced  users. 

The  Product  5  embedded  training  component  will  contain  modular 
lessonware.  Specific  topics  will  be  organized  into  lessons,  which  can  be 
taken  independently  by  a  user.  An  overall  syllabus  structure  will  guide 
initial  training,  but  the  user  will  not  be  constrained  to  take  the  training 
modules  in  any  specific  order.  Following  the  syllabus  structure  for  new 
users  will  be  encouraged,  however. 

The  following  major  lesson  topics  will  be  included  in  the  syllabus: 

•  Basics  I  -  Introduction  to  the  Manpower  Estimation  Method  and 
Software  System 

•  Basics  II  -  Input  Data  Requirements  and  Data  Input  Practice 

e  Basics  III  -  Understanding  and  Interpreting  Manpower  Estimates 

•  Advanced  Topics  I  -  How  System  Tasks  are  Clustered 

t  Advanced  Topics  II  -  How  Jobs  are  Formed  from  Task  Clusters 

•  Advanced  Topics  III  -  Sensitivity  Analyses:  Changing 
Input  Data  to  Affect  Manpower  Estimates 

The  basic  modules  are  designed  to  enable  the  new  user  to  use  the 
product  to  derive  manpower  requirements  from  system  design  estimates.  The 
advanced  modules  are  for  more  experienced  or  interested  users,  or  those  who 
need  to  use  the  more  advanced  capabilities  of  the  product. 

Guided  practice  and  sample  solved  problems  will  be  included  in  the 
function.  Much  of  the  training  provided  by  the  component  will  consist  of 
hands-on  exercises  with  extensive  guidance  for  the  user.  Exercises  will 
concentrate  on  accomplishing  specific  steps  of  using  the  product,  and  will 
contain  error  diagnostics  (comparing  the  user's  performance  with  that  of  an 
idealized  Product  5  user)  to  enable  feedback  and  learning  from  errors. 
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The  function  will  contain  a  balanced  mix  of  knowledge  and  hands-on 
training.  Some  users  will  be  uninterested  in  how  the  product  works  and  will 
wish  to  emphasize  practical  capabilities.  Others  will  develop  an  interest 
in  how  the  product  does  what  it  does  to  produce  its  outputs.  The  content 
and  structure  of  training  will  accommodate  both  extremes,  as  well  as  many 
intermediate  points  on  the  "theory-practice"  continuum. 

When  users  are  tasked  to  develop  manpower  estimates,  it  is  likely  that 
a  timely  response  will  be  particularly  important.  Thus,  we  will  structure 
training  to  enable  the  user  to  work  with  basic  features  and  capabilities  of 
the  product  first.  If  the  user  later  has  later  has  time  and  interest,  he  or 
she  can  "add  on"  training  in  how  to  work  with  such  features  as  the 
sensitivity  analysis  capability. 

An  additional  function  is  "checkpoint  and  resume."  The  product's  users 
are  busy  people  with  many  demands  on  their  time.  We  will  therefore  not 
constrain  the  user  to  dedicate  time  to  complete  even  a  single  module  of 
training  at  one  session.  Each  user's  progress  in  training  will  be  monitored 
by  a  control  feature  in  the  component,  and  a  user  will  be  able  to  suspend 
training  at  any  point  and  resume  from  the  same  point  at  a  later  time. 

We  anticipate  that  the  component  will  be  capable  of  enabling  a 
completely  naive  user  to  develop  basic,  "no-frills"  manpower  estimates  for  a 
new  system  after  a  maximum  of  four  hours  training  time.  The  advanced 
lessons  will  take  approximately  1-2  hours  each. 


Context-Sensitive  Help  and  Explanation  Facility 

This  facility  will  enable  the  user  to  request  help  and  explanations  at 
any  time  the  user  is  actually  interacting  with  Product  5.  Context 
sensitivity  of  this  feature  refers  to  the  fact  that  the  product  will  have 
information  about  what  the  user  is  attempting  to  accomplish  during  any 
interaction.  Using  this  information,  the  product  will  provide  guidance  and 
explanations  of  how  to  accomplish  the  particular  function.  The  product  will 
also  be  able  to  present  information  regarding  why  particular  inputs  and 
judgments  are  needed  to  accomplish  the  interaction.  Guidance  will  always  be 
provided  when  the  user  invokes  the  help  capability.  "Why"  information  will 
only  be  presented  at  the  explicit  request  of  the  user. 

The  user  interface  with  the  help  and  explanation  capability  will  be 
through  a  "hot-key"  approach,  with  one  function  key  (or  the  equivalent) 
always  set  aside  to  request  help.  If  the  information  contained  in  the  help 
or  explanation  requires  more  than  one  full  display  screen  to  present,  the 
user  will  use  the  normal  up  and  down  cursor-control  or  scrolling  keys  to 
move  forward  or  backward  through  the  information  presented.  If  there  are 
options,  choices,  or  responses  associated  with  a  help  or  explanation 
display,  the  user  will  be  presented  with  a  "pull-down"  menu  of  choices, 
above  the  normal  display  area  for  help  information.  Choices  will  me  made  by 
moving  a  block  cursor  to  the  desired  option  or  response  (using  the  left  and 
right  cursor  control  keys)  and  using  an  "enter"  or  execute  key  to  invoke  the 
choice  desired. 
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As  mentioned  in  earlier  sections,  the  help  function  will  provide 
assistance  in  entering  input  data.  These  help  screens  will  lead  the  user  to 
structure  input  data  properly. 
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USER  ACCEPTANCE  PLAN 


The  Product  5  User 

At  present,  manpower  estimates  are  developed  by  AMC  and  TRADOC  and 
monitored  by  DCSOPS  with  concurrence  from  DSCPER.  In  AMC,  the  Engineering 
Section  develops  Basis  of  Issue  Plan  Feeder  Data  (BOIPFD).  The  New 
Equipment  Training  Section  of  the  major  supporting  command  develops  the 
Quantitative  and  Qualitative  Personnel  Requirements  Inventory  (QQPRI)  which 
relates  to  manpower  requirements.  Based  on  the  major  support  command  draft 
BOIPFD  and  QQPRI,  HQTRADOC  through  the  integrating  centers  will  charge  the 
combat  and  training  developers.  The  combat  developer  provides  comments  on 
the  draft  proposed  job  specifications  furnished  by  the  materiel  developer. 
The  combat  developer  provides  justification  for  any  change  to  the  QQPRI. 

The  training  developer  provides  an  estimate  of  the  amount  of  formal  on-the- 
job  training  required  (TRADOC  Form  799-R).  HQTRADOC  will  provide  copies  of 
the  QQPRI  along  with  the  school  and  integrating  centers'  comments  to  the 
Equipment  Authorization  Review  Activity  (EARA).  EARA  forwards  this  to  the 
Project  Manager  and  New  Equipment  Training  personnel.  Three  additional 
copiesPare  sent  to  Soldier  Support  Center,  National  Capital  Region  (SSC- 
NCR).  SSC-NCR  develops  the  proposed  operator  and  maintainer  decision 
regarding  new  or  improved  equipment.  HQTRADOC  will  send  the  documents 
received  from  SSC-NCR  to  HQDA  for  approval.  DCSOPS  with  DCSPER  concurrence 
has  the  final  approval. 

The  DCSPER  MANPRINT  personnel  responsibilities  are  evolving  given  that 
the  MANPRINT  system  is  relatively  new  as  an  institutional  entity.  However, 
MANPRINT  office  personnel  are  concerned  with  developing  and  monitoring 
manpower  requirements  of  new  systems.  At  present,  the  Manpower  Requirements 
Determination  Module  of  the  Man  Integrated  Systems  Technology  (MIST)  package 
is  used  by  MANPRINT  personnel  (both  in  the  government  and  by  contractors)  to 
develop  maintenance  manpower  estimates.  However,  Product  5  may  be  seen  as  a 
more  helpful  tool.  MIST  estimates  manpower  requirements  by  determining  the 
number  of  maintenance  man-hours  required  of  each  MOS  to  support  the  system 
for  a  specified  time  period,  adjusted  for  individual  work  capacity.  MIST 
then  computes  the  number  of  people  who  must  be  available  per  MOS  by  dividing 
the  requirement  by  an  availability  factors.  The  Product  5  approach  is 
distinguished  from  the  MIST  approach  in  that  the  Product  5  approach  produces 
the  number  of  personnel  required  to  support  both  operations  and  maintenance 
jobs,  and  bases  these  estimates  on  system  design  requirements,  rather  than 
basing  the  projection  on  the  percent  of  available  MOS  required. 

Potential  Product  5  users,  military  and  civilian,  then,  will  be  found 
in  several  Army  agencies.  The  assumption  is  made  that  the  system  must  be 
friendly  to  maximize  its  chances  for  adoption.  In  addition,  the  assumption 
is  made  that  each  user  will  have  available  input  data  at  varying  levels  of 
development.  Therefore,  Product  5  is  designed  to  provide  output  using  data 
ranging  from  scant  to  sophisticated.  The  discussion  below  describes  our 
approach  to  providing  potential  users  with  a  Product  5  that  they  will 
accept. 
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Causes  and  Results  of  Poor  User  Acceptance 


Even  when  the  performance  of  software  design  is  excellent,  the  problem 
remains  of  how  to  encourage  its  use  in  the  field  (Donnell,  Fineberg,  and 
Carter,  1987).  Procedures  for  improving  implementation  and  use  require  an 
understanding  of  the  user's  attitudes  and  perceptions  toward  the  product  and 
its  use.  The  user's  background  and  experience  with  computers  affect  user 
acceptance.  The  fit  of  the  product  within  the  context  of  the  existing  job 
situation  will  affect  user  acceptance.  If  the  user  detects  conflicts 
between  product  use  and  existing  doctrine,  acceptance  will  be  poor. 

Finally,  product  performance  will  affect  user  acceptance.  The  product  must 
run  reliably  with  little  downtime  and  product  outputs  that  are  correct. 

Some  of  the  specific  problems  listed  in  Donnell  et  al .  (1987)  that  may 
cause  poor  user  acceptance  include: 

•  Lack  of  user  confidence,  reflecting  perceived  unreliability,  often 
resulting  from  failures,  errors,  or  breakdowns  in  the  sensitive 
early  stages  of  system  introduction. 

•  Divergence  from  perceived  function,  where  the  hardware  or  software 
manifestation  of  the  system  is  at  odds  with  the  user's  idea  of  what 
it  does  or  should  do. 

•  Divergence  from  individual  needs,  where  the  user  feels  that  his  or 
her  specific  requirements,  preferences,  tastes,  etc.,  are  ignored 
or  even  offended  by  specific  system  characteristics. 

•  Divergence  from  individuality,  where  the  user  feels  unable  to 
influence  the  system  personally. 

•  Threat  to  privacy,  where  the  user  feels  he  or  she  is  liable  to  some 
form  of  exposure  (data  or  decisions)  as  a  result  of  system  use. 

•  Threat  to  security  of  self-esteem.  Of  particular  importance  to 
acceptance,  this  often  reflects  the  reluctance  of  well -placed  users 
to  make  themselves  look  foolish  by’failing  to  master  seemingly 
complex  new  technology.  It  may  also  reflect  a  personal  conclusion 
that  one's  job  is  vulnerable  to  computer  encroachment-  or, 
alternatively,  that  computer  use  diminishes  the  status  of  that  job 
by  incorporating  menial  elements. 

Poor  user  acceptance  results  in  a  variety  of  user  responses.  A  list  of 
common  responses  is  presented  in  Figure  15.  If  user  acceptance  problems  are 
discovered  before  the  system  is  fielded,  solutions  will  be  easy  to  remedy. 
One  of  the  major  goals  of  Product  5  is  to  avoid  user  acceptance  problems 
early  in  the  development  process.  To  do  this  it  is  essential  that  measuring 
user  acceptance  be  an  integral  part  of  all  Product  5  development  efforts. 

User  acceptance  of  computer  systems  is  a  frequently  neglected  aspect  of 
software  evaluation.  User  acceptance  is  a  function  of  ease  of  use  and 
perceived  usefulness  of  output.  The  software  developer  typically  evaluates 
product  effectiveness  in  terms  of  speed,  accuracy,  quality  of  output,  and 
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Response  Definition  Comments 

Dis-Use  Reliance  on  other  information  Requires  existence  of  alternative 

sources.  information  source,  user  with 

sufficient  discretion. 


4- 

1  4-> 

1 

41 

•» 

o 

(J  00 

< 

01 

01 

•<—  O 

ai 

-  C 

u 

4- 

41  < 

Ol  4-> 

n-  E 

4- 

X  •»- 

u 

C  E 

CPI  u 

4/1 

u 

wo 

(  4-> 

rO  4. 

X  ro 

•p  C  M 

WO 

OO  wo 

4-  C 

«*->  O 

Ol  CL 

4->  i-  0) 

•r- 

•*“  rO  • 

X 

01  01 

CL4- 

• 

E 

flj  *p 

X  4- 

s-  cn 

4-J  •*— 

01  4- 

5  — 

</>  a>  +-> 

O 

P  c 

2 

3  U 

U  01 

CTN 

o 

X  f—  •*— 

x 

OJ  T3  -r- 

o 

Q.  CO 

U  CL 

c  >> 

r— 

c  ai 

i_  a;  > 

r— 

E 

rO 

J*  I— 

4-»  4->  •>- 

ro  co 

re  U  r— 

O  wo 

4, 

Ol 

aox> 

C 

3  O 

4- 

41  ro  • 

4-  O 

+J  > 

O  C 

WO  O 

DO  DO 

o 

W 

01  O 

c  •— 

■o  a. 

3  CL 

1—  o 

4-  ^  01 

CO  Q. 

X 

na  4-> 

<0  >,  (t> 

4->  WO 

O  3  E 

CO 

O  L  V) 

3 

o 

41  to  • 

re  u 

ro  01 

O  i-  CD 

w 

01  3 

o 

*•—  Ol  >■» 

>0  E 

4->  S- 

+J  4-»  r— 

01  • 

O)  wo 

4-  WO 

0) 

p~  E 

WO 

DO  X 

wo  wo 

00  3  a> 

O  01 

c  — 

*->  p  0) 

r— 

c  c  o 

3  J* 

c  c 

c 

C  4- 

C  >0*J 

-C  tO 

0)  3  Sp 

4. 

O  X  •*- 

^  to 

>o  o> 

ID  Quo 

CT>  u 

x  a. 

-c  a> 

a  oi  4 

O  4- 

X 

*»■  It  Q) 

3  ID  >i 

•r-  *f“ 

3e  do 

4->  r— 

CO  4-^  01 

tO 

c 

CO  ^  +-> 

cr*j  io 

_C  CL 

•p-  o 

•*-  u 

01  ro  01 

»—  i. 

ro 

c 

OI  ro 

>> 

• 

-p- 

U  41  C 

o 

</)  •#- 

i~  U  *-> 

WO  h— 

WO 

C  pH- 

wo 

wo  4. 

CD  • 

<4-  4->  C 

01 

4- 

ai  E  — 

f—  ro 

P—  4-> 

CD  S- 

01 

i-  E  E 

oo  ro 

4. 

01 

r—  ft)  4-> 

ro 

ro  wo  C 

>  01 

wo 

01  Q) 

DO  > 

« 

cr> 

re  r—  C 

O  ^ 

41  01 

f— 

• 

E 

D  4J 

J-  X  0) 

3  C 

ro 

>  X  0) 

•f-  C 

JC 

O  -C 

01 

ro 

cr  oo  wo 

a;  o'-— 

cr  o 

c 

a;  o  •<- 

a.  o 

CL  CL  X 

>  C71  Cl 

cc 

ai  »>  >o 

VI  C  01 

CD  •*- 

ro 

i-  i-  o 

>%  o  c 

C  -p- 

c 

a  vo  vi 

O  —  J- 

CC  4-> 

E 

a.  a.  do 

H-  4-> 

H—  wo  ro 

p->  X 

ro 

E 

o 

4- 

4- 

r' 

^  , 

i  • 

ai  do 

S.  wo 

E 

CO 

4-»  «u 

01  01 

01 

J-  o> 

<e  •*- 

x  •- 

0) 

4-> 

o  •*- 

•<-  +J 

X 

f— 

4.  4-J 

> 

WO 

-C  4-> 

t-  — 

S- 

o 

ro 

o  •- 

o  s- 

to  1— 

Xr— 

O  • 

4-> 

C 

X  o 

LT) 

3 

O  -p- 

^  E 

re  • 

E  O 

c  •»- 

re 

o  o 

$-  X) 

ro  Ol 

E  E 

o>  •*- 

■P-  -O 

0) 

01 

4->  •*“ 

X  re 

L  4-> 

a> 

4->  4-> 

ro 

C  4-> 

4-> 

4- 

x  a. 

01  WO 

O  -D-> 

wo  •*- 

Q. 

0)  re 

ro 

s  4- 

re  re 

CL  >> 

X  DO 

>iX 

4.  ro 

X  =3 

3 

t/)  •»— 

C  (J 

o  WO 

>> 

wo  x 

o>  U 

3!  O’ 

cr 

Ol  X 

•p 

DO 

ro 

CO 

0) 

01 

E 

4-  X 

DO 

L. 

3  E 

i-  T3 

X 

3  r- 

DO  a) 

O  C 

ro  4- 

O  >» 

01 

CD  ro 

• 

ro 

4-  ro 

X-M 

ro 

4->  O 

4-  -O 

* 

i/i  c 

C. 

C 

ro  do 

C 

• 

-O  wo  co 

3  •— 

4- 

ai  o 

-C  >i 

o  4- 

V  i/I 

C  WO 

CO 

>>X 

O 

.c 

J-  DO 

•1-  01 

x  ai 

O  01 

C 

to  01 

id-  a> 

4-> 

o 

4->  +-> 

ai 

+->  wo 

4->  -P- 

•»—  •»— 

O 

C  01 

O  i. 

u 

4-> 

Q.<4- 

•»-  3 

4-» 

4->  U 

*»-  >»  c 

ro 

ro 

4- 

—  o 

to 

OV- 

ro  ro 

4-> 

E  4- 

0) 

4- 

WO 

c  oi 

o  c 

C  i— 

wo  3 

u 

E  •*-  4-> 

DO  DO 

wo 

01 

•*-  CL 

<*-  4-> 

Q-  CD 

•p  -p 

C  O' 

ro 

ro  X  •— 

C  C 

•r— 

wo 

x  O 

O  0) 

4-  (D 

aix 

01  01 

1-0  3 

o  o 

4-> 

C 

c 

1/1 

a;  3: 

c  re 

ax 

L- 

WE  vo 

x->- 

ro 

O 

0)  4-J 

0)  X) 

4->  4-> 

re  X 

E  w 

01 

O 

DO  X 

wo 

CL 

GO  3 

DO  3 

C  01 

X  re 

O  C 

wo 

l-  o  o 

a>  u 

C 

wo 

s  U 

=>  DO 

•— 1  -O 

(_>  Ip) 

o  •*- 

3 

CL  W-J  4-> 

a;  re 

3 

01 

03 


i- 


Ol 

wo 

X 

c 

>>4-l 

o 

i.  ■— 

C 

o  > 

c 

o  >> 

• 

4-> 

4->  -P- 

•r-  ^ 

I/O 

ro 

ro  4-> 

E 

4->  4-> 

0) 

4-> 

41  J* 

DO  u 

E 

ro  ro 

wo 

40 

c 

</) 

C  <t 

4->  ro 

4-  CL 

01 

X 

ro 

<4-  re 

a) 

O  4. 

•*-»  C 

&- 

i 

4-J 

4-> 

•p-  ►- 

X  i- 

Ol  CD 

wo 

3 

wo 

U  01 

WO  0) 

■o 

E  0) 

4-  O 

3  X 

CD 

•F> 

ro  wo 

wo 

O  14- 

O  l/l 

•r-  4. 

4.  C 

•»“ 

2 

O.  z> 

O  3) 

Z  o 

O  X 

O  Q- 

u.  ro 

U. 

E2-58 


the  extent  to  which  it  improves  human  performance.  However,  users  reject 
even  highly  effective  software  systems  for  any  number  of  reasons.  Two 
important  reasons  are  ease  of  use  and  perceived  usefulness.  Therefore,  the 
software  developer  alone  cannot  judge  the  effectiveness  the  the  product. 
Users  must  also  judge  the  product  as  easy  to  use  and  useful. 


Designing  for  Ease  of  Use 

The  general  notion  of  user  acceptance  includes  both  ease  of  use  and 
perceived  usefulness.  Another  way  to  view  this  issue  is  in  terms  of 
reliability  of  use  and  validity  of  output.  If  a  software  system  does  not 
have  both  these  attributes,  then  it  will  not  be  accepted  by  the  user.  Four 
areas  will  be  considered  in  evaluating  ease  of  use:  the  skill  levels  of 
potential  users;  the  type  and  specificity  of  feedback  given  to  users;  the 
consistency  between  what  users  request  and  what  they  receive,  and  memory 
demands  the  software  system  places  on  users  (Liffick,  1985). 

Based  on  an  operator  skill  evaluation,  the  user  interface  will  be 
designed  to  match  the  skill  of  the  users.  The  interface  will  provide 
embedded  training  for  the  novice  user.  The  information  the  novice  user  must 
have  to  make  a  decision  must  be  known  and  available.  Experienced  users  may 
need  less  information  in  order  to  use  the  system.  Given  the  newness  of  this 
software  system,  it  can  be  assummed  that  users  will  be  novices.  Therefore, 
it  will  be  necessary  to  create  a  dynamic  system,  one  that  changes  as  the 
user  becomes  familiar  with  it.  Product  5  will  include  separate  tracks  for 
different  user  experience  levels. 

The  points  at  which  a  novice  user  becomes  an  experienced  used  is  not 
easy  to  define.  It  is  usually  not  the  case  that  one  day  the  user  is  a 
novice,  and  the  next  he  or  she  is  experienced.  Even  an  experienced  user 
might  want  to  use  a  feature  he  or  she  has  not  tried  before,  and  regress 
briefly  to  the  novice  stage.  Product  5  will  allow  an  experienced  user  to 
function  as  a  novice,  on  demand,  then  return  to  the  experienced  used  mode. 
Switching  from  experienced  to  novice  mode  will  be  simple,  and  the  user  will 
clearly  know  where  he  or  she  is  in  the  system. 

Information  to  the  user  is  critical  in  ease  of  use.  Menus  and  feedback 
provide  the  information  the  user  needs  to  navigate  through  the  system. 
Systems  described  as  user  friendly  are  usually  menu  oriented.  Feedback,  no 
matter  how  simple,  is  important  to  keep  the  user  informed  about  every  action 
that  has  been  requested.  Feedback  lets  the  user  know  what  the  system  is 
doing,  so  the  user  knows  that  what  has  been  requested  has  been  accomplished. 
Given  the  many  suspicions  that  novice  users  tend  to  have  about  computers, 
this  is  important.  All  feedback  should  be  positive.  When  the  user  has  done 
something  incorrect,  the  system  will  clearly  identify  the  incorrect  action 
as  well  as  a  direction  about  how  to  continue.  This  keeps  the  user  from 
having  to  guess  what  to  do  next. 

User  effectiveness  is  increased  where  there  is  consistency  in  rules, 
and  little  ambiguity.  Ambiguity  requires  the  user  either  to  make  a  decision 
with  incomplete  information,  or  waste  time  searching  the  documentation  for  a 
resolution  to  the  ambiguity.  Therefore,  consistent  procedures  will  be 
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established  for  user  interactions.  The  consistent  use  of  rules  will  allow 
the  user  to  make  assumptions  about  how  things  work  within  the  system. 

It  is  important  to  minimize  the  demands  on  human  memory.  A  help 
function  for  the  user  is  the  ideal  way  to  limit  memory  requirements.  Such  a 
function  can  usually  be  entered  at  any  time  by  the  user.  The  help  function 
provides  details  about  how  each  part  of  the  system  works,  what  the  various 
commands  of  the  system  are,  and  what  what  the  formats  for  inputs  are.  If 
the  user  needs  more  information  than  is  provided  in  the  help  function,  he  or 
she  will  also  have  the  option  of  entering  novice  mode.  As  mentioned  above, 
the  user  will  be  able  to  return  to  experienced  used  mode  when  the  additional 
help  is  no  longer  needed. 


Enhancing  Perceived  Usefulness 

Participation  in  product  design  by  the  user  may  well  lead  to  a  match 
between  what  the  software  developer  sees  as  effective  and  what  the  user  sees 
as  useful.  User  acceptance  is  a  combination  of  reliability,  ease  of  use, 
and  validity  and  perceived  usefulness  of  output.  No  single  one  of  those  is 
sufficient  for  user  acceptance.  For  example,  the  Product  5  user  may  find 
Product  5  easy  to  use,  but  of  no  particular  value.  In  that  case,  user 
acceptance  is  low.  In  contrast,  the  user  may  find  the  product  difficult  to 
use  but  of  great  value;  the  user  may  struggle  to  use  the  product,  but  user 
acceptance  will  be  low. 

The  concept  of  product  usefulness  may  be  measured  subjectively  and 
objectively.  Subjective  measures  evaluate  the  attitude  of  the  user  toward 
the  product,  e.g.,  is  the  product  helpful?  is  it  difficult  to  use?  does  it 
seem  to  be  effective?  Objective  measurments  can  also  be  taken.  Variables 
to  be  measured  objectively  should  be  directly  related  to  the  user's  job  and 
measurable  by  the  software  developer,  for  example,  frequency  of  use,  length 
of  session,  use  of  output,  and  improved  human  performance.  By  selecting  job 
relevant  dimensions  to  measure,  there  is  a  good  chance  that  the 
effectiveness  sought  by  the  software  developer  will  closely  match  the 
perceived  usefulness  of  Product  5  by  the  user. 


Assessment  of  User  Acceptance 

User  acceptance  of  Product  5  will  be  measured  objectively  and 
subjectively.  A  subjective  assessment  indicates  how  satisfied  the  user  is 
with  the  system,  and  is  accomplished  through  user  interview  and 
questionnaire  responses.  An  objective  assessment  indicates  how  much  the 
user  uses  the  system,  and  is  made  by  monitoring  actual  system  use. 

Subjective  data  concerning  user  accepance  can  be  obtained  via 
structured  interviews  or  questionnaires.  User  acceptance  and  product 
usefulness  are  the  two  broad  categories  used  in  subjective  evaluation 
(Donnell  et  al . ,  1987).  Users  will  be  asked  to  rate  Product  5  on  the 
following  dimensions  of  user  acceptance. 

1.  The  system  is  matched  to  the  user. 
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2.  The  system  provides  the  critical  variables  needed  to  solve  the 
problem. 

3.  This  product  can  handle  a  typical,  complex  manpower  estimation 
problem. 

4.  The  product  does  not  add  to  the  already  considerable  information 
overload  within  the  operational  and  organization  planning  effort. 

5.  Use  of  the  product  will  not  require  more  expertise  from  the  typical 
user  than  is  likely  to  be  available  in  the  operational 
environment. 

6.  People  can  easily  under  the  procedures  to  be  followed  in  using 
Product  5. 

7.  The  product  provides  a  common  language,  facilitating  easy 
communications  between  members  of  the  decision  making  team. 

8.  The  product  contributes  to  the  essential  flow  of  intergroup 
information,  or  communications,  necessary  for  effective  decision 
making. 

9.  The  use  of  the  product  is  consistent  with,  and  would  not  interfere 
with  operational  and  organizational  planning. 

10.  A  user  can  be  confident  in  Product  5  decisions. 

11.  If  implemented  in  an  operational  environment,  use  of  the  Product  5 
can  be  expected  to  increase  as  time  progresses. 

12.  The  use  of  Product  5  in  an  operational  environment  is  a  realistic 
goal  for  the  near  future. 

Product  5  users  will  also  rate  the  Product  on  the  following  dimensions 
of  Product  effectiveness: 

1.  Product  5  enables  sufficiently  rapid  and  complete  responses  to  aid 
the  manpower  estimation  process. 

2.  Product  5  encourages  the  user  to  explicitly  identify  relevant 
objectives  and  to  prioritize  them. 

3.  Product  5  encourages  effective  response  to  the  issues  most  relevant 
to  determination  of  manpower  requirements  of  system  designs. 

4.  A  Product  5  user  can  readily  prepare  data,  input  data,  and  extract 
understandable  results. 

5.  Product  5  encourages  the  decision  maker  to  consider  a  wide  range  of 
options  or  possible  system  alernatives. 
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6.  Product  5  encourages  one  to  think  critically  and  realistically 
about  problems  and  prospects  for  implementation  of  the  selected 
decision. 

7.  Product  5  focuses  and  enhances  appropriate  and  constructive 
decision  maker  discussion  concerning  the  issue  under  consideration. 

8.  Product  5  possesses  considerable  generality  so  that  many  different 
problems  can  be  relatively  easily  accommodated. 

9.  The  value  of  the  product  will  increase  as  the  complexity  of 
problems  to  which  it  is  applied  increases. 

Objective  measures  of  user  acceptance,  such  as  the  duration  and 
frequency  of  user  sessions,  and  the  time  taken  to  generate  a  manpower 
estimate,  should  also  be  studied.  This  will  be  done  in  as  unobtrusive 
manner  as  possible,  with  no  demands  placed  on  the  user's  time. 


Involving  the  User  in  Development 

The  Product  5  team  has  identified  likely  users  of  the  product.  These 
people  will  be  consulted  during  product  development.  This  will  prevent 
potential  users  from  feeling  as  though  the  Product  has  been  forced  upon  them 
by  outsiders,  a  quick  guarantee  of  user  rejection.  The  Product  5  approach 
does  not  burden  Army  subject  matter  experts.  Therefore,  we  will  be  able  to 
use  our  meetings  with  potential  users  to  let  them  critique  the  approach  and 
our  plans  for  development  and  implementation.  In  addition  we  plan  to  test 
Product  5  with  in-house  Army  experts  to  avoid  presenting  a  product  that 
looks  "civilian."  Our  goal  is  to  provide  potential  users  with  a  reliable, 
simple  to  use  product,  that  immediately  offers  them  help  in  improving  their 
jobs.  We  plan  to  set  up  a  "User  Interest  Group"  that  will  remain  together 
from  the  detailed  design  phase  to  production  and  implementation. 
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PRODUCT  5  DEVELOPMENT  CYCLE 


Overview 


The  software  development  of  Product  5  must  be  evaluated  to  assure  that 
it  meets  all  functional  requirements.  The  software  must  have:  the  type  of 
data  the  user  needs,  algorithms  which  include  variables  important  to  the 
user,  decision  rules  formulated  using  experts,  and  output  that  is  accepted 
by  the  user  because  it  makes  sense  and  is  useful.  The  software 
developmental  process  keeps  the  end  user  in  mind. 

The  Product  5  lifecycle  validation,  verification,  and  testing  (VV&T) 
process,  including  software  development  and  maintenance,  will  ensure 
software  quality,  user  acceptance,  and  ease  of  use.  The  VV&T  process  is  a 
procedure  of  review,  analysis,  and  testing  used  throughout  the  software 
lifecycle.  Val idation  determines  the  correctness  of  the  final  program  or 
software  with  respect  to  the  software  requirements.  Verification  employs 
integrity  and  evolution  checking  to  determine  internal  consistency  and 
completeness.  Testing,  either  automated  or  manual,  examines  program 
behavior  by  executing  the  program  on  sample  data  sets.  The  software 
lifecycle  is  the  period  of  time  beginning  with  the  software  concept 
development  and  ending  when  the  resultant  software  products  are  no  longer 
aval  able  for  use. 

The  software  VV&T  cycle  is  broken  into  five  phases:  requirements 
determination,  design,  programming  and  testing,  installation,  and  operations 
and  maintenance  (Federal  Information  Processing  Standards  Publication, 

1983).  These  five  phases  represent  milestones  in  the  software  development 
process,  and  provide  excellent  points  for  user  inspection.  Use  of  these 
five  phases  improves  direct  project  management.  Software  developers  and 
maintainers  have  a  well  defined  set  of  tasks  to  perform.  Verifiers,  by 
checking  the  products  of  these  tasks,  can  verify  that  the  project 
requirements  are  met  at  each  of  the  five  phases.  Table  3  presents  an 
outline  of  lifecycle  VV&T  activities. 


Phase  I.  Requirements  Definition  and  Analysis 

This  phase  consists  of  four  parts:  development  of  the  project 
validation,  verification,  and  testing  plan;  generation  of  requirements- 
based  test  cases  (scenarios);  review  and  analysis  of  the  requirements,  and 
review  and  analysis  of  the  draft  user  manual (s). 

The  project  plan  explains  the  strategy  for  managing  the  development  of 
the  software  for  Product  5.  This  documen*  defines  the  general  software 
development  process  for  all  phases  of  the  project,  estimates  resource 
requirements,  and  specifies  intermediate  milestones,  including  management 
and  technical  reviews.  It  defines  methods  for  design,  coding,  verification, 
validation  and  testing,  document  reporting,  and  change  control.  A  basic  set 
of  test  cases  will  be  developed  to  clarify  and  to  determine  measurability  of 
each  software  requirement.  The  acceptance  criteria  developed  during  subject 
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Table  3 


Lifecycle  VV&T  Activities  (from  Federal  Information  Processing  Standards 
Publications,  1983) 


PHASE  I .  Requirements  Definition  and  Analysis 

•  Development  of  the  project  verification  and  validation  plan 

•  Generation  of  requirements-based  test  cases 

•  Review  and  analysis  of  the  requirements 

•  Review  and  analysis  of  the  draft  user  manual 


PHASE  II.  Design 

•  Completion  of  Verification  and  Validation  plan 

•  Generation  of  design-based  test  scenarios 

•  Review  and  analysis  of  the  design 

•  Premliminary  design  integrity  check 

•  Preliminary  design  evolution  check 

•  Development  of  test  support  software 


PHASE  III.  Programming  and  Testing 

•  Completion  of  test  case  specification 

•  Review,  analysis,  and  testing  of  the  program 

•  Code  integrity  check 

•  CoJe  evolution  check 

•  Unit  test 

•  Integration  test 

•  System  test 


PHASE  IV.  Installation 
•  System  acceptance 


PHASE  V.  Operations  and  Maintenance 

•  Software  evaluation 

•  Software  modification  eva'  ation 

•  Regression  testing 
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matter  experts  will  be  used  to  develop  the  test  cases.  Input  data  and 
expected  results  for  each  test  case  will  be  included  in  the  specification. 

The  software  requirements  document  will  specify  what  the  system  must 
do,  including  the  requisite  information  flows,  processing  functions, 
performance  constraints,  and  the  acceptance  criteria  for  deciding  that 
specific  requirements  have  been  satisfied.  Subject  matter  experts  and 
software  developers  will  work  together  to  develop  this  knowledge  base 
structure.  In  addition,  this  document  will  also  contain  those  internal 
specifications  which,  although  transparent  to  the  end  user,  are  necessary 
for  the  development  of  the  end  product.  Project  requirements  are  reviewed 
for  clarity,  completeness,  consistency,  testability,  and  traceability  to  the 
problem  statement.  This  activity  ensures  that  the  requirements  result  in  a 
practical,  usable  solution  to  the  appropriate  area. 

Analysis  techniques  in  the  requirements  phase  include  static  and 
dynamic  analysis.  Static  analysis  focuses  on  checking  adherence  to 
specification  conventions,  consistency,  completeness,  and  language  syntax. 
Dynamic  analysis  focuses  upon  information  flows,  functional 
interrelationships,  and  performance  requirements.  Manual  methods  such  as 
inspections,  peer  reviews,  and  "walkthroughs"  are  effective  in  accomplishing 
both  types  of  analysis.  If  the  constructs  of  the  requirements  specification 
scheme  are  clearly  defined  and  capable  of  being  represented  in  a  computer 
processable  form,  then  automated  tools  may  be  used  to  perform  both  static 
and  dynamic  analyses. 

User  manuals  will  be  drafted.  Each  will  describe  software  system  use 
for  each  product  in  non-technical  language.  Each  manual  will  describe  both 
the  system  functionality  and  the  user  interface.  Manual  preparation  during 
the  requirements  phase  is  an  excellent  mechanism  for  ensuring  that  both  the 
users  and  the  developers  share  the  same  view  of  the  system.  The  manual 
serves  as  a  reference  document  for  the  preparation  of  input  data  and  as  a 
useful  tool  in  setting  parameters  for  interpretation  of  the  results.  The 
users'  manual  will  be  reviewed  for  clarity  and  consistency.  It  will  be 
checked  for  completeness  against  the  requirements  document.  In  addition, 
this  verification  activity  will  ensure  that  the  internal  specifications  of 
the  requirements  document  are  defined  sufficiently  to  produce  the  functions 
and  interfaces  described  in  the  users'  manual. 


Phase  II.  Design 

The  purpose  of  the  design  phase  is  to  generate  a  complete  solution  to 
the  Product  5  problem.  The  best  solution  has  already  been  selected.  During 
design  specification,  a  high-level  specification  is  developed  which  defines 
information  aggregates,  information  flows,  logical  processing  steps,  and  the 
solution  in  terms  of  algorithms  and  data  structures.  The  result  is  a 
solution  specification  that  can  be  implemented  in  code  with  little 
additional  refinement. 

The  design  specification  contains  two  parts:  (1)  a  preliminary 
design  section  to  identify  the  high-level  solution,  and  (2)  a  detailed 
design  section  that  defines  software  (algorithms  and  data)  to  be  coded  in 
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the  subsequent  phase.  The  design  will  be  analyzed  to  ensure  internal 
consistency,  completeness,  correctness,  and  clarity,  and  to  verify  that  the 
design,  when  implemented,  will  satisfy  the  requirements. 

As  incorrect,  inconsistent,  infeasible,  or  ambiguous  requirements  are 
discovered,  revised  requirements  specifications  will  be  developed.  The 
detailed  design  plan  may  indicate  the  need  for  additional  testing. 

Additional  test  scenarios  and  test  cases  (input  data  and  expected  results) 
will  be  developed  to  exercise  and  test  logical  and  structural  aspects  of  the 
design.  Development  or  acquisition  of  any  support  software  needed  for  unit, 
integration,  or  system  testing  will  be  completed  and  installed  during  the 
detailed  design  phase  to  ensure  readiness  during  programming  and  testing. 

Design  specification  schemes  specify  algorithms  and  their  inputs  and 
outputs  in  terms  of  modules.  Inconsistencies  in  specifying  the  flow  of  data 
through  the  modules  can  be  detected  by  static  analysis  techniques.  Dynamic 
analysis  of  the  design  is  accomplished  by  simulation.  This  may  be  a  manual 
"walkthrough"  or  an  automated  simulation  using  a  model  of  the  design.  The 
higher  the  model  fidelity,  the  higher  the  cost  of  the  simulation.  This  cost 
generally  increases  with  the  complexity  of  the  model.  Formal  analysis 
techniques  involve  tracing  paths  through  the  design  specification  and 
formulating  a  composite  function  of  each.  The  purpose  of  deriving  these 
composite  functions  for  a  given  level  of  design  is  to  compare  them  to  the 
functions  of  the  previous  level.  This  process  ensures  that  the  design 
continues  to  specify  the  same  functional  solution  as  is  hierarchically 
elaborated  in  the  schematic  decision  tree  presented  in  the  user  manual. 


Phase  III.  Programming  and  Testing 

During  this  phase,  the  detailed  design  is  implemented  in  code, 
resulting  in  a  program  or  system  ready  for  installation.  Three  tests  are 
performed  on  the  software:  unit,  integration,  and  system.  The 
programmer  is  responsible  for  unit  testing.  The  project  manager  determines 
the  responsibility  for  integration  and  system  testing,  depending  on  the 
project  size  and  criticality. 

Unit  testing  looks  for  typographic,  syntactic,  and  logical  errors  in 
the  code.  Programmers  will  also  check  to  ensure  that  each  module  correctly 
implements  its  design  and  satisfies  the  specific  requirements.  Static 
analysis  techniques  and  tools  are  used  to  ensure  the  proper  form  of  code  and 
documentation.  Dynamic  analysis  techniques  are  employed  to  study  the 
functional  and  computational  correctness  of  the  code.  Initially,  manual 
"walkthroughs"  can  be  used  as  an  effective  forerunner  to  testing.  Testinq 
for  adherence  to  assertions,  produced  during  design,  is  important  during 
this  phase. 

Integration  testing  focuses  on  checking  intermodule  communication  links 
and  on  testing  aggregate  functions  formed  by  groups  of  modules.  System 
testing  examines  the  operation  of  the  system  as  an  entity,  and  in  a 
simulated  environment.  This  ensures  that  the  software  requirements  have 
been  satisfied  both  singly  and  in  combination  with  other  "real  life" 
variables  found  in  the  user's  environment.  Sample  data  will 
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be  used  in  testing  initial  prototypes.  These  sample  data  tests  evaluate  the 
procedures,  decision  rules,  and  algorithms  chosen  for  use  in  the  product. 

The  final  activity  of  this  phase  is  to  ensure  readiness  of  the 
software  installation,  including  revision  of  plans  as  necessary  and 
completion  of  all  other  coding,  testing,  and  documentation.  Fully 
documented  and  tested  code  is  constructed  and  prepared  for  installation. 
Manuals  describing  the  input  and  report  formats,  user  commands,  error 
messages,  and  instructions  for  operation  by  the  user  are  completed.  Final 
revisions  and  additions  to  the  test  data  are  made.  Based  on  prototype 
testing,  recommendations  for  revisions  are  made;  subject  matter  expert  input 
is  important.  Retesting  ensures  confidence  in  the  results  and  demonstrates 
ease  of  use.  Actual  results  are  compared  with  expected  results  to  validate 
the  product's  output.  Results  of  validation  testing  are  documented. 

Problems  are  recorded  formally  and  resolved  as  necessary. 


Phase  IV.  Installation  Phase 


This  phase  evaluates  and  modifies  software,  if  necessary,  to  ensure 
user  acceptance.  To  accomplish  this,  the  system  is  placed  in  operation. 

The  final  step,  integrating  the  system  components,  includes  installing 
hardware,  installing  the  program  on  the  computer,  reformatting/creating  the 
data  base,  and  verifying  that  all  components  have  been  included. 

Modification  of  the  program  code  may  be  necessary  to  obtain  compatibility 
between  hardware  and  software,  or  between  different  software  modules  for 
which  earlier  simulation  testing  may  not  have  been  adequate.  The 
installation  report  describes  the  results  of  installation  activities, 
including  data  conversion,  and  software  and  system  problems  and 
modifications.  User  acceptance  and  user  friendliness  will  be  validated. 

Next,  the  system  is  tested  in  its  complete  operating  environment.  The 
result  is  a  system  qualified  and  accepted  for  production  use.  The 
installation  report  also  includes  operational  test  results. 

Next  is  the  start  of  system  operation.  Interfacing  with  on¬ 
going  software  systems  will  be  a  prime  consideration  to  save  money  and 
mputer  storage  space,  in  the  likely  event  that  the  product  computer  serves 
multiple  purposes.  A  strategy  for  this  will  be  devised.  A  completely  new 
program  could  either  be  phased  into  operation  or  could  be  be  implemented  at 
once.  This  task  also  includes  operator  and  user  training. 


Phase  V.  Operations  and  Maintenance 

The  operations  and  maintenance  phase  is  the  time  of  actual  use  of  the 
product  in  the  operational  environment.  User  evaluation  continues,  and 
modifications  desired  are  channeled  through  a  formal  request  for 
modification  process.  This  project's  plan  does  not  call  for  contractor 
monitoring  through  the  operations  and  maintenance  phase. 
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INSTITUTIONALIZING  PRODUCT  5 


There  are  two  approachs  that  will  be  used  to  institutionalize  the 
product.  One  is  to  take  "campaign"  actions  to  institutionalize  the  product, 
and  the  second  is  to  build  into  the  product  inherent  characteristics  that 
will  help  insure  its  institutionalization. 


Campaign  Actions  Taken  to  Institutionalize  the  Product 

The  institutionalization  plan  includes  three  campaign  action  items. 
These  are  (1)  involving  potential  users  in  the  development  process,  (2) 
securing  the  support  of  a  general  officer,  and  (3)  teaching  product  use  to 
Army  personnel  within  their  training  courses. 

Involving  the  potential  users  of  the  product  in  all  stages  of  product 
development  occurs  first  in  time.  As  described  earlier,  users  will  be  found 
in  AMC,  TRADOC,  DCSOPS,  and  DCSPER.  Potential  users  will  be  involved  in  the 
design  and  testing  stages  through  both  informal  commenting  and  more  formal 
pilot-testing.  A  frequent  dialogue  will  be  established  with  the  more 
cooperative  potential  users.  They  will  be  asked  for  input  on  data  base 
items  and  structures  and  interface  design.  In  addition,  their  opinions  on 
the  more  basic  procedures  of  the  product  will  be  sought. 

These  are  three  reasons  for  the  involvement  of  the  potential  users. 
First,  their  involvement  helps  to  develop  a  critical  mass  of  positive 
potential  users  prior  to  the  availability  of  the  product.  They  will  help 
institutionalize  the  product  by  usin''  it  and  promoting  it.  Second, 
potential  users  help  tailor  the  product  to  their  needs  and  desires.  This 
will  make  it  a  more  attractive  product  and  thus  help  insure  its 
institutionalization.  Finally,  Product  5  developers  want  to  be  able  to  say 
we  consulted  with  the  users  in  the  development  of  the  product  and  that  we 
have  their  support  and  approval. 

The  second  campaign  action  item  will  be  to  obtain  the  support  of  a 
general  officer.  This  will  be  accomplished  after  the  product  is  partially 
developed  so  that  its  rudiments  can  be  shown  and  demonstrated.  Also,  the 
support  of  the  users  will  help  gain  the  support  of  a  general  officer.  In 
addition,  briefings  the  efficiency,  cost  effectiveness,  and  other  benefits 
of  the  product  will  be  given  as  needed. 

The  third  campaign  action  item  is  to  have  the  use  of  the  product 
included  in  the  courses  taught  to  Army  users.  It  should  be  possible  to 
include  a  new  module  in  these  courses  specifically  devoted  to  promoting  the 
product.  In  addition,  besides  promoting  the  product,  the  course  will  teach 
Army  personnel  how  to  use  the  product  and  make  users  familar  and  comfortable 
with  it.  All  of  these  additions  to  Army  courses  will  hel p  institutionalize 
the  product. 
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Inherent  Features  Fostering  Institutionalization 


There  are  four  features  which  will  be  inherent  characteristics  of  the 
product  or  results  it  will  yield.  All  four  will  foster  its 
institutionalization.  They  are: 

•  Face  valid 

•  Lowers  cost  of  Army  personnel  manpower  estimation 

•  Lowers  cost  of  system  development 

•  Produces  a  formatted  audit  trail 

Face  validity  will  come  through  interaction  with  the  users  during  the 
development  and  testing  of  the  product.  Face  validity  will  go  a  long  way 
toward  institutionalizing  the  product.  Face  validity  will  partially  result 
from  the  users'  feedback.  Such  feedback  will  provide  guidance  for  the  the 
design  and  development  of  the  product.  Thus  it  will  have  the  look  and  feel 
of  the  users. 

In  many  cases,  the  product  will  result  in  a  reduction  of  the  amount  of 
labor  required  to  produce  accurate  system  manpower  estimates.  This  feature 
of  the  product  will  almost  in  and  of  itself  cause  it  to  be 
institutionalized.  Many  system  development  efforts  have  resulted  in  elegant 
systems  that  were  never  used.  Often  this  was  because  the  systems  required 
the  users  to  do  more  than  they  did  before.  On  the  other  hand,  everyone 
appreciates  a  job  aid  that  actually  makes  their  job  easier  especially  if  it 
is  because  they  have  to  do  less.  The  reduced  labor  will  result  in  a  less 
costly  manpower  estimation  process. 

Similarly,  the  product  will  lead  to  a  lower  cost  for  the  evaluation  of 
system  designs  than  was  previously  experienced.  This  will  be  the  result  of 
having  specific  manpower  estimates  available  before  system  production, 
alleviating  costly  modifications  that  would  have  to  occur  if  manpower 
requirements  of  the  new  system  were  excessive.  Thus  will  be  avoided  any 
costly  redesign  efforts  prior  to  developmental  testing  and  any  retro- ,'itting 
after  operational  testing.  In  addition,  examining  manpower  estimates  before 
production  also  will  help  the  system  avoid  having  to  undergo  the  typical 
product  improvement  efforts  after  fielding.  All  of  these  reduced  cost 
aspects  will  be  effective  in  obtaining  the  support  of  a  general  officer. 

The  product  will  result  in  a  formatted  audit  trail  which  will  document 
each  system  manpower  estimation  effort.  This  will  be  an  especially 
attractive  feature  of  the  product,  because  the  present  process  often  leads 
to  poorly  answered  questions  about  manpower  requirements.  Part  of  the 
reason  for  the  present  process  resulting  in  poorly  answered  questions  is 
that  the  process  is  not  procedural ized.  The  present  process  provides  no 
format  or  easy  to  use  vehicle  for  generating  an  audit  trail. 
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APPENDIX  A 

KAPLAN  &  CROOKS  TAXONOMY 
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SYSTEMS  MISSIONS 
(Categorized  by  Class  of  System) 
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SYSTEM  MISSIONS 


AIR  DEFENSE  WEAPONS  Including: 
Short  Range  Missiles,  Medium  Range 
Missiles,  Long  Range  Missiles,  Air 
Defense  Guns,  High  Energy  Systems 

1.  Destroy  aircraft. 

2.  Confuse  and  disrupt  aircraft. 

3.  Deny  selected  airspace/forma¬ 
tion  to  attacking  aircraft. 

4.  Destroy  ground  targets. 

5.  Protect  operator/crew  from 

enemy  action. 


ARMORED  VEHICLES  Including:  Main 
Battle  Tanks,  Armored  Reconnaissance 
Vehicles/Llght  Tanks,  Infantry/ 
Cavalry  Fighting  Vehicle,  Armored 
Personnel  Carriers  Mounting  Anti- 
Tank  Weapons 

1.  Destroy  fixed  emplacements. 

2.  Destroy  armored  vehicles. 

3.  Destroy  enemy  personnel. 

4.  Destroy/disrupt  enemy  aircraft. 

5.  Suppress/disrupt  enemy  ac¬ 
tivity. 

6.  Serve  as  a  platform  for  moun¬ 
ted  attack. 

7.  Transport  troops/materiel. 

8.  Perform  reconnaissance. 

9.  Protect  crew/passengers/ 

materiel  from  enemy  action. 


AVIATION  SYSTEMS  including: 

Attack  Helicopters,  Scout  Helicopters, 
Transport  Helicopters,  Utility  Heli¬ 
copters,  Fixed-Wing  Reconnaissance, 
Fixed-Wing  Transport 

1.  Destroy  enemy  vehicles. 

2.  Destroy  anti-aircraft  systems. 

3.  Destroy  fixed  emplacements. 

4.  Destroy  enemy  personnel. 

5.  Disrupt/suppress  enemy  activity. 

6.  Perform  reconnaissance. 

7.  Serve  as  platform  for  electron¬ 
ics  warfare  systems. 

8.  Transport  troops/materiel. 


AVIATION  SYSTEMS  (Continued) 

9.  Transport  injured  troops. 

10.  Protect  crew/passengers/ 
materiel  from  enemy  action. 

BATTLEFIELD  COffiUNICATION  SYSTEMS 
including:  Man-Portable  Radios, 
Vehicle-Portable  Radios,  Visual 
Conmuni cations  Systems,  and  Base 
Radio  Systems 

1.  Transfer  information  and 
orders  between  concerned 
units/individuals. 

2.  Protect  system/crew  from 
enemy  action. 

C2/C2«I  SYSTEMS  including:  Field 
Artillery  Fire  Control,  Tank  Fire 
Control,  Air  Defense  Fire  Control 

1.  Provide  information  on  cur¬ 
rent  battlefield  conditions 
and  situation. 

2.  Provide  projections  of  pro¬ 
bable  future  conditions  and 
enemy  behavior. 

3.  Control  the  behavior  of 
friendly  forces. 

4.  Manage  friendly  weapon  op¬ 
eration. 

5.  Manage  logistics. 

£.  Conmuni cate  information  to 
appropriate  units. 

7.  Protect  system/crew  from 
enemy  action. 


COMBAT/TACTICAL  SUPPORT  EQUIPMENT 
including:  Combat  Engineer  Veh¬ 
icles,  Recovery  Vehicles,  Demoli¬ 
tion  Equipment,  and  Bridging 
Equipment 

1.  Destroy/remove  obstacles/ 
roadblocks. 

2.  Construct  obstacles/road¬ 
blocks. 
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SYSTEM  MISSIONS 


COMBAT/TACTICAL  SUPPORT  EQUIPMENT 
(Continued) 

3.  Bridge  obstacles. 

4.  Construct  emplacement/shelters. 

5.  Transport  command  posts. 

6.  Transport  damaged  vehicles. 

7.  Destroy  armored  vehicles/ 
personnel . 

8.  Protect  crew/material  from 
enemy  action. 


ELECTRONIC  WARFARE  AND 

SURVEILLANCE  SYSTEMS  including: 

Countermeasures  Equipment  and 

Sighting  and  Surveillance  Equip¬ 
ment 

1.  Provide  critical  information  on 
potential  targets. 

2.  Confuse/disrupt/disable  enemy 
systems. 

3.  Protect  operator/crew  from 
enemy  action. 

4.  Jam  electronic  signals. 

5.  Produce  false  targets/target 
signatures. 


GROUND  TRANSPORTATION  EQUIPMENT 
including:  1/4  Ton  Utility  Trucks, 
3/4  to  1-1/2  Ton  Trucks,  5  Ton 
Trucks,  8  to  10  Ton  Trucks,  Heavy 
Equipment  Transport  Trucks 

1.  Transport  command  personnel. 

2.  Transport  troops. 

3.  Transport  materiel. 

4.  Serve  as  an  ambulance. 

5.  Protect  operator/crew  from  enemy 

action. 


INFANTRY  WEAPONS  including:  Pistols/ 
Revolvers,  Rifles,  Sub-Machine  6uns, 
Machine  Guns,  Recoilless  Rifles,  Anti- 
Tank  Missile  Systems,  Anti-Aircraft 
Missile  Systems,  Grenades/Grenade 
Launchers,  Anti-Armor  Mines,  Anti- 
Personnel  Mines,  Flamethrowers,  Mortars 


INFANTRY  WEAPONS  (Continued) 

1.  Destroy  enen\y  vehicles. 

2.  Destroy  low  flying  enemy  air¬ 
craft. 

3.  Destroy  fixed  emplacements. 

4.  Destroy  enemy  troops. 

5.  Disrupt/suppress  enemy  ac¬ 
tivity. 

6.  Provide  illimination. 

7.  Protect  operator/crew  from 

enemy  action. 

8.  Conceal  friendly  forces  by 
making  smoke. 


ORDNANCE  SYSTEMS  including:  Light, 
Towed,  Tube  Artillery;  Light, 
Self-Propelled,  Tube  Artillery; 
Medium,  Towed,  Tube  Artillery; 
Medium  Self-Propelled,  Tube 
Artillery;  Heavy,  Towed  Tube 
Artillery;  Battlefield  Support 
Guided  Missile;  Battlefield 
Support  Unguided  Missiles;  Multi¬ 
ple  Launch,  Guided  Missiles; 
Multiple  Launch,  Unguided  Missiles 

1.  Destroy  fixed  emplacements 

on  or  behind  the  battlefield. 

2.  Destroy  enemy  vehicles/wea¬ 

pons. 

3.  Destroy  enemy  personnel. 

4.  Suppress/deny  enemy  activity, 
and  deny  terrain  to  enemy. 

5.  Provide  illumination. 

6.  Conceal  friendly  forces  by 

making  smoke. 

7.  Protect  crew/materia  1' from 

enemy  action. 


TARGET  ACQUISITION  AND/OR 
DESIGNATOR  SYSTEMS 

1.  Provide  critical  Information 
on  potential  targets. 

2.  Designate/m uminate  target. 

3.  Protect  system/crew  from 
enemy  action. 
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TEMPLATES  OF  SYSTEM  FUNCTIONS 
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SYSTEM  FUNCTIONS 


COMMAND  AND  CONTROL 

1.  Representation  of  battlefield 
conditions. 

2.  Representation  of  status  of 
forces. 

3.  Projection  of  battlefield 
operations. 

4.  Projection  of  weather  condi¬ 
tions. 

5.  Selection  and  ordering  of 
targets. 

6.  Management  of  weapon  func¬ 
tions. 

7.  Personnel  planning. 

8.  Logistics  recommendations. 

9.  Selection  of  friendly  forces. 

10.  Battlefield  control  of  friendly 
forces. 


COMMUNICATIONS 

1.  Establishment  and  maintenance 
of  conmuni cations. 

2.  Prevention  of  interception/ 
jamming. 

3.  Information  routing. 


ENGINEERING 

1.  Vehicle  recovery. 

2.  Obstacle  removal. 

3.  Bridging. 


MANEUVERABILITY 

1.  Navigation. 

2.  Maneuver  in  travel. 

3.  Maneuver  in  attack/defense. 

4.  Self-Recovery. 


TARGET  ACQUISITION  AND  DESIGNATION 
(PERFORMED  BY  INDEPENDENT 
ACQUISITION  AND/OR  DESIGNATION 
SYSTEMS) 

1.  Acquistion  of  targets. 

2.  Target  information  gathering 
and  interpretation. 

3.  Target  behavior  prediction. 

4.  Delivery  of  designator  on 
target. 


TRANSPORTATION 

1.  Ability  to  be  transported. 

2.  Delivery  of  cargo. 

3.  Loading/Unloading. 


VULNERAB I L ITY / SURV I VAB I L I TY 

1.  Prevention  of  detection/ 
location. 

2.  Escape  from  system. 

3.  Protection  of  operator(s), 
etc. 

4.  Movement  of  system,  between 
operations,  to  prevent 
location. 


WEAPON  DELIVERY 

1.  Target  acquisition. 

2.  Delivery  of  aimunition  on 
target. 

3.  Engagement  of  several  tar¬ 
gets. 


RECONNAISSANCE 

1.  Information  gathering. 

2.  Fire  control -reconnaissance. 
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TEMPLATES  OF  TASKS  (OPERATIONS) 

(Categorized  by  System  Function) 
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OPERATIONS  TASKS 


BATTLEFIELD  RECONNAISSANCE 

1.  Identify  key  environmental 
features. 

2.  Identify  current  weather 
conditions. 

3.  Identify  key  elements  of 
threat  force. 

4.  Identify  essential  Infor¬ 
mation  for  evaluating  NBC 
contamination  hazard  out¬ 
er  limits. 

5.  Identify/select  routes. 

6.  Present  Information  about 
routes  which  could  In¬ 
fluence  movement. 

7.  Identify  hazards  to  move¬ 
ment. 

8.  Identify  early  warning  of 
enemy  threat. 

9.  Report  map  changes. 


CONTROL  OF  FRIENDLY  FORCES  ON 

THE  BATTLEFIELD 

1.  Determine  commander's  de¬ 
sired  outcome  and  priorities. 

2.  Determine  the  tactics  to  be 
followed. 

3.  Select  the  most  appropriate 
friendly  unlt(s)  to  engage 
In  operation.  (The  follow¬ 
ing  types  of  units  should 

be  considered:  first  echelon, 
reserve.  Intelligence, 
counter- Intel 1 1 gence , 
maintenance,  logistics.) 

4.  Determine  travel  routes  for 
friendly  units. 

5.  Determine  departure  and 
projected  arrival  times  for 
friendly  units. 

6.  Prepare  contingency  plans 
and  the  situations  In  which 
each  Is  to  be  Implemented. 

7.  Prepare  plans,  orders,  maps 
and  other  required  documents. 

8.  Prepare  materials  for  brief¬ 
ing  commanders  and  staffs. 


E2-A- 


CONTROL  OF  FRIENDLY  t’ORCES  ON  THE 

BATTLEFIELD  (Continued) 

9.  Monitor  units'  compliance 
with  orders  and  their  prog¬ 
ress. 

10.  Identify  critical  situations 
which  indicate  significant 
changes  In  battlefield  op¬ 
erations. 

11.  Update  plans/orders  as  battle¬ 
field  situation  changes. 


ENGINEERING-BRIDGING 

1.  Prepare  bridge  site. 

2.  Excavate  foundations. 

3.  Construct  bridge  abutments. 

4.  Construct  bridge  span. 

5.  Construct/assemble  bridge. 

6.  Prepare  bridge  for  launching. 

7.  Position  bridge  transporter 
for  launching. 

8.  Launch/drive  bridge  into 
water. 

9.  Connect  bridge. 

10.  Recover  bridge. 

11.  Disassemble  bridge. 


ENGINEERING-OBSTACLE  REMOVAL/ 

BREACHMENT 

1.  Acquire  obstacle  to  be  dealt 
with. 

2.  Prepare  system  hardware  for 
obstacle  removal /breaching. 
The  nature  of  this  prepara¬ 
tion  is  entirely  dependent 
upon  the  sort  of  system 
under  consideration.  It 
may  Involve  preparation  for 
bulldozing,  gun  firing,  dem¬ 
olition,  etc. 

3.  Decide  on  placement  of  fire, 
charge,  or  pressure  In  re¬ 
lation  to  obstacle. 

4.  Remove/breach  obstacle. 

5.  Remove/displace  remains  of 
obstacle. 


OPERATIONS  TASKS 


ESCAPE  FROM  SYSTEM 

1.  Destroy  or  alter  critical  com¬ 
ponents  of  communication  and 
other  sensitive  equipment/ 
documents. 

2.  Take  personal  weapon,  ammuni¬ 
tion,  and  survival  equipment. 

3.  Position  system  for  escape, 

If  possible  under  the  condi¬ 
tions  imposed. 

4.  Open  escape  path  out  of 
system. 

5.  Escape  from  system. 


ESTABLISHMENT  AND  MAINTENANCE  OF 

COMMUNICATIONS 

1.  Assemble  communications  de- 
vice(s). 

2.  Assemble/erect/orient 
antenna. 

3.  Establish  communications 
net. 

4.  Enter  communications  net. 

5.  Transmit  messages. 

6.  Receive  messages. 


INFORMATION  ROUTING 

1.  Identify  appropriate  recip¬ 
ients  of  information. 

2.  Prioritize  recipients  for 
the  delivery  of  information. 

3.  Prioritize  pieces  of  infor¬ 
mation  for  delivery. 

4.  Assign  security  classifi¬ 
cation  and  method  for  main¬ 
taining  that  classification. 

5.  Determine  call  signals/ 
frequencies. 


LOGISTICS 

1.  Maintain  Information  on 
current  status  of  supplies. 

2.  Maintain  Information  on  main 
tenance  status  of  equipment 
needed  for  mission. 


LOGISTICS  (Continued) 

3.  Recommend  location  of  rear 
boundary  bases. 

4.  Recommend  main  and  secondary 
supply  routes. 

5.  Determine  throughput  unit 
supply  requirements. 

6.  Recommend  movements  which 
are  consistent  with  lo¬ 
gistics  considerations. 

7.  Develop  policies  for  area 
damage  control  operations. 

NAVIGATION 

1.  Select  appropriate  maps  and/ 
or  navigation  aids. 

2.  Identify  present  location. 

3.  Identify  destination. 

4.  Select  travel  route. 

5.  Estimate  time  of  arrival  and 
fuel  requirements. 

6.  Travel  designated  route. 

7.  Identify  position  or  route 
at  specified  times/loca- 
ti ons . 


PERSONNEL  PUNNING 

1.  Prepare  personnel  estimate 
based  on  requirements  of 
operation. 

2.  Estimate  casualty  rates  of 
friendly  forces  and  project¬ 
ed  POW's. 

3.  Prepare  evacuation  contin¬ 
gency  plans. 

4.  Coordinate  personnel  re¬ 
placement  plans  with  appro¬ 
priate  organizations. 


PREVENTION  OF  DETECTION/LOCATION 
OF  SYSTEM 

1.  Detect  threat  warning! s) 
which  indicate  either 
search  or  attack  modes. 
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OPERATIONS  TASKS 


PREVENTION  OF  DETECTION/LOCATION 

OF  SYSTEM  (Continued) 

2.  Identify  the  nature  of  the 
threat (s)  from  which  de¬ 
tected  threat  warnings 
emanate. 

3.  Take  appropriate  counter¬ 
measures  to  reduce  the 
probability  of  identifi¬ 
cation  of  location. 

(These  countermeasures 
Include:  jamming,  smoke» 
flares,  chaff,  powered 
decoys,  signature  alter¬ 
ation,  and  electronic 
attack  of  threat-sensing 
equipment.) 

4.  Camouflage  system.  (System 
camouflage  includes: 
physical.  Infrared,  and 
radar  signature  reduction.) 


PREVENTION  OF  INTERCEPTION/ 
JAMMING 

1.  Encode  messages. 

2.  Authenticate  transmissions. 

3.  Decode  messages. 

4.  Apply  anti-janming  pro¬ 
cedures  . 

5.  Apply  transmission  security 
procedures. 


PROJECTION  OF  BATTLEFIELD 

OPERATIONS 

1.  Determine  observable  Indi¬ 
cators  of  possible  changes 
in  the  operational  situa¬ 
tion. 

2.  Prioritize  Indicators  of 
operational  changes. 

3.  Assign  intelligence  col¬ 
lection  tasks  to  maximize 
receipt  of  Indicators 
according  to  their  prior¬ 
ities. 


PROJECTION  OF  BATTLEFIELD 

OPERATIONS  (Continued) 

4.  Monitor  intelligence  col¬ 
lection  and  reassign  tasks 
based  on  updated  informa¬ 
tion. 

5.  Display  pertinent  informa¬ 
tion. 

6.  Identify  Important  miss¬ 
ing  Information. 

7.  Identify  Important  informa¬ 
tion  which  is  internally 
Inconsistent  or  probably 
inaccurate. 

8.  Develop  alternate  sources 
of  information. 

9.  Determine  which  model (s) 
of  expected  enemy  behavior 
best  fits  collected  infor¬ 
mation. 

10.  Assign  confidence  levels 
to  the  projection(s). 

11.  Make  recommendations  about 
the  effects  of  projected 
operations. 

12.  Prioritize  information 
according  to  user(s)  need 
and  probability  of  accuracy. 

13.  Prioritize  list  of  informa¬ 
tion  users  for  receipt  of 
information  based  on  their 
functions  in  this  specific 
operation  and  their  require¬ 
ments. 


PROJECTION  OF  HEATHER  CONDITIONS 

1.  Collect  relevant  weather 
information  for  the  appli¬ 
cable  area(s). 

2.  Develop  alternative  weather 
projections  and  their  indi¬ 
cators. 

3.  Assign  probabilities  to 
weather  projections. 

4.  Determine  effects  of  alter¬ 
nate  weather  projections  on 
operation(s). 
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OPERATIONS  TASKS 


PROJECTION  OF  HEATHER  CONDITIONS 

(Continued) 

5.  Prioritize  indicators  of 
weather  projections. 

6.  Assign  weather  Indicator 
collection  tasks. 

7.  Monitor  weather  Indicator 
collection  and  reassign  tasks 
based  on  updated  information. 

8.  Update  projection  probabili¬ 
ties. 

9.  Collect,  order  and  display 
pertinent  information. 

10.  Identify  important  missing 
Information. 

11.  Identify  Important  informa¬ 
tion  which  Is  Internally  In¬ 
consistent  or  probably  in¬ 
accurate. 

12.  Develop  alternate  sources  of 
information. 

13.  Prioritize  information  accord 
ing  to  users'  needs  and 
probability  of  accuracy. 

14.  Prioritize  lists  of  informa¬ 
tion  users  for  receipt  of 
Information  based  on  their 
functions  in  this  specific 
operation  and  their  require¬ 
ments. 


RECONNAISSANCE/FIRE  CONTROL 

1.  Determine  target  type/number/ 
size/di rection/speed/eleva- 
tlon. 

2.  Determine  weather  conditions 
affecting  weapons  delivery. 

3.  Determine  target  coordinates. 

4.  Mark  target  locations;  this 
may  be  done  by  physical, 
chemical,  radiological  or 
electronic  means. 

5.  Handoff  target(s)  to  attack 
units. 

6.  Determine  effects  of  fire 
on  target. 

7.  Relocate  target(s). 

E2-A- 


RECONNAISSANCE/FIRE  CONTROL 
(Continued) 

8.  Adjust  fire  of  attacking 
unit(s). 


REPRESENTATION  OF  FORCES’  STATUS 

1.  Indicate  location (s)  of 
forces. 

2.  Indicate  composition 
(number  and  type)  of 
forces. 

3.  Indicate  availability  of 
forces. 

4.  Indicate  peculiarities/ 
weaknesses  of  forces. 

5.  Indicate  recent  significant 
tactical  events  in  which 
specific  units  were  involv¬ 
ed. 

6.  Indicate  actions  which 
forces  are  currently 
pursuing.  (Your  consider¬ 
ation  of  these  actions 
should  include:  direction 
of  movement,  speed  of  move¬ 
ment,  and  apparent  pur¬ 
pose's)  of  movement.) 

7.  Indicate  the  enemy  comnan- 
der’s  previous  behavior 

In  similar  situations. 

8.  Indicate  combat  effective¬ 
ness  of  forces. 

9.  Indicate  relative  combat 
power  of  enemy  to  friendly 
units. 

10.  Indicate  relevant  threat 
potentials  of  enemy  forces. 

11.  Identify  important  missing 
Information. 

12.  Identify  important  infor¬ 
mation  which  is  internally 
Inconsistent  or  probably 
Inaccurate. 

13.  Develop  alternate  sources 
of  information. 


OPERATIONS  TASKS 


PROJECTION  OF  WEATHER  CONDITIONS 

(Continued) 

5.  Prioritize  Indicators  of 
weather  projections. 

6.  Assign  weather  Indicator 
collection  tasks. 

7.  Monitor  weather  Indicator 
collection  and  reassign  tasks 
based  on  updated  Information. 

8.  Update  projection  probabili¬ 
ties. 

9.  Collect,  order  and  display 
pertinent  information. 

10.  Identify  important  missing 
information. 

11.  Identify  important  informa¬ 
tion  which  is  internally  in¬ 
consistent  or  probably  in¬ 
accurate. 

12.  Develop  alternate  sources  of 
information. 

13.  Prioritize  information  accord¬ 
ing  to  users'  needs  and 
probability  of  accuracy. 

14.  Prioritize  lists  of  informa¬ 
tion  users  for  receipt  of 
information  based  on  their 
functions  in  this  specific 
operation  and  their  require¬ 
ments. 


RECONNAISSANCE/FIRE  CONTROL 

1.  Determine  target  type/number/ 
size/direction/speed/eleva- 
tion. 

2.  Determine  weather  conditions 
affecting  weapons  delivery. 

3.  Determine  target  coordinates. 

4.  Mark  target  locations;  this 
may  be  done  by  physical, 
chemical,  radiological  or 
electronic  means. 

5.  Handoff  target (s)  to  attack 
units. 

6.  Determine  effects  of  fire 
on  target. 

7.  Relocate  target(s). 


RECONNAISSANCE/FIRE  CONTROL 
(Continued) 

8.  Adjust  fire  of  attacking 
unit(s). 


REPRESENTATION  OF  FORCES'  STATUS 

1.  Indicate  location(s)  of 
forces. 

2.  Indicate  composition 
(number  and  type)  of 
forces. 

3.  Indicate  availability  of 
forces. 

4.  Indicate  peculiarities/ 
weaknesses  of  forces. 

5.  Indicate  recent  significant 
tactical  events  in  which 
specific  units  were  involv¬ 
ed. 

6.  Indicate  actions  which 
forces  are  currently 
pursuing.  (Your  consider¬ 
ation  of  these  actions 
should  include:  direction 
of  movement,  speed  of  move¬ 
ment,  and  apparent  pur- 
pose(s)  of  movement.) 

7.  Indicate  the  enetny  comman¬ 
der's  previous  behavior 

in  similar  situations. 

8.  Indicate  combat  effective¬ 
ness  of  forces. 

9.  Indicate  relative  combat 
power  of  enemy  to  friendly 
units. 

10.  Indicate  relevant  threat 
potentials  of  enemy  forces. 

11.  Identify  important  missing 
information. 

12.  Identify  important  infor¬ 
mation  which  is  internally 
inconsistent  or  probably 
inaccurate. 

13.  Develop  alternate  sources 
of  information. 


E2-A-12 


OPERATIONS  TASKS 


SELECT  THE  MOST  APPROPRIATE 

FRIENDLY  UNIT(S)  TO  ENGAGE  IN 

OPERATION  (Continued) 

2.  Order  these  requirements 
based  on  commander's  prior¬ 
ities. 

3.  Identify  friendly  unlt(s) 
with  the  appropriate  mix  of 
attributes  to  match  the  pri¬ 
oritized  requirements. 

4.  Determine  which  friendly 
units,  with  the  correct  at¬ 
tributes,  can  be  removed 
from  their  present  opera¬ 
tions  without  unacceptable 
consequences . 

5.  Determine  the  transportation 
systems  required  to  move 
each  friendly  unit  to  the 
operational  area. 

6.  Determine  the  availability 
of  each  transportation 
system  required  to  move 
each  friendly  unit  and  the 
time  required  for  it  to 
perform  Its  function. 

7.  Determine  the  logistics 
required  by  each  friendly 
unit  to  perform  its  functions 
In  the  operation  In  question. 

8.  Determine  the  availability 
of  the  supplies  and  delivery 
systems  to  the  operations 
area  for  the  required  lo¬ 
gistics  of  each  friendly  unit. 

9.  Display  all  significant  In¬ 
formation  and  order  it  In 
some  logical  and  helpful 
manner. 


SELECTION  AND  ORDERING  OF 
APPROPRIATE  TARGETS 

1.  Locate  potential  targets. 

2.  Identify  type  and  number  of 
potential  targets. 

3.  Determine  threat  potentials 
of  targets. 


SELECTION  AND  ORDERING  OF 

APPROPRIATE  TARGETS  (Continued) 

4.  Determine  availability  of 
appropriate  friendly  weapon 
system. 

5.  Determine  the  probability 
of  eliminating  target(s). 

6.  Prioritize  targets. 

7.  Select  targets  to  attack. 


SELF-RECOVERY 

1.  Prepare  system  for  self¬ 
recovery. 

2.  Reconnoiter  for  appropriate 
anchor  points  and  recovery 
path. 

3.  Position  anchors. 

4.  Attach  cables  to  anchors/ 
winches. 

5.  Pull  system  to  safe  area. 

6.  Disassemble/stow  self¬ 
recovery  components. 


SYSTEM  PROTECTION  FROM  THREAT 

1.  Identify  threat  to  system 
(e.g.,  onboard  fire,  flood 
ing.  Imminent  crash,  NBC, 
enemy  attack). 

2.  Activate  hardware  protec¬ 
tive  device(s). 

3.  Put  on  protective  gear/ 
clothing. 

4.  Secure  material /cargo  for 
protection  against  threat. 

5.  Assume  protective  position 
for  crew/passengers. 

6.  Maneuver  to  protect  from 
threat. 

7.  Deactivate  hardware  pro¬ 
tective  device(s). 
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OPERATIONS  TASKS 


SELECT  THE  HOST  APPROPRIATE 

FRIENDLY  UNIT(S)  TO  ENGAGE  IN 

OPERATION  (Continued) 

2.  Order  these  requirements 
based  on  commander's  prior¬ 
ities. 

3.  Identify  friendly  unit(s) 
with  the  appropriate  mix  of 
attributes  to  match  the  pri¬ 
oritized  requirements. 

4.  Determine  which  friendly 
units,  with  the  correct  at¬ 
tributes,  can  be  removed 
from  their  present  opera¬ 
tions  without  unacceptable 
consequences. 

5.  Determine  the  transportation 
systems  required  to  move 
each  friendly  unit  to  the 
operational  area. 

6.  Determine  the  availability 
of  each  transportation 
system  required  to  move 
each  friendly  unit  and  the 
time  required  for  it  to 
perform  its  function. 

7.  Determine  the  logistics 
required  by  each  friendly 
unit  to  perform  Its  functions 
In  the  operation  In  question. 

8.  Determine  the  availability 
of  the  supplies  and  delivery 
systems  to  the  operations 
area  for  the  required  lo¬ 
gistics  of  each  friendly  unit. 

9.  Display  all  significant  in¬ 
formation  and  order  it  in 
some  logical  and  helpful 
manner. 


SELECTION  AND  ORDERING  OF 
APPROPRIATE  TARGETS 

1.  Locate  potential  targets. 

2.  Identify  type  and  number  of 
potential  targets. 

3.  Determine  threat  potentials 
of  targets. 


SELECTION  AND  ORDERING  OF 
APPROPRIATE  TARGETS  (Continued) 

4.  Determine  availability  of 
appropriate  friendly  weapon 
system. 

5.  Determine  the  probability 
Of  eliminating  target(s). 

6.  Prioritize  targets. 

7.  Select  targets  to  attack. 


SELF-RECOVERY 

1.  Prepare  system  for  self¬ 
recovery. 

2.  Reconnoiter  for  appropriate 
anchor  points  and  recovery 
path. 

3.  Position  anchors. 

4.  Attach  cables  to  anchors/ 
winches. 

5.  Pull  system  to  safe  area. 

6.  Disassemble/stow  self¬ 
recovery  components. 


SYSTEM  PROTECTION  FROM  THREAT 

1.  Identify  threat  to  system 
(e.g.,  onboard  fire,  flood¬ 
ing,  inminent  crash,  NBC, 
enen\y  attack). 

2.  Activate  hardware  protec¬ 
tive  device(s). 

3.  Put  on  protective  gear/ 
clothing. 

4.  Secure  material /cargo  for 
protection  against  threat. 

5.  Assume  protective  position 
for  crew/passengers. 

6.  Maneuver  to  protect  from 
threat. 

7.  Deactivate  hardware  pro¬ 
tective  device(s). 
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OPERATIONS  TASKS 


TARGET  INFORMATION  GATHERING  AND 

INTERPRETATION  (Continued) 

7.  Identify  target. 

8.  Determine  nunber  of  targets. 

9.  Determine  target  location/ 
range. 

10.  Determine  target  speed. 

11.  Determine  target  direction. 

12.  Determine  target  formation/ 
tactical  situation. 

13.  Select  and  order  targets 
based  on  the  matching  of 
priorities  with  target  In¬ 
formation  gathered. 

14.  Recognize  countermeasures  and 
take  appropriate  action. 


VEHICLE  MANEUVERING— GROUND 

VEHICLES 

1.  Observe  environment  for  ob¬ 
stacles,  landmarks,  etc. 

2.  Read  and  use  Instruments 
appropriate  to  vehicle  ma¬ 
neuvering. 

3.  Perform  the  following,  mov¬ 
ing  backward  (B)  and/or  for 
ward  (f).  Circle  B  or  F  as 


appropriate. 

3.1  Tight  turn.  B  F 

3.2  Wide  turn.  B  F 

3.3  Accelerating  turn.  B  F 

3.4  Decelerating  turn.  B  F 

3.5  Rapid  acceleration.  B  F 

3.6  Gradual  acceleration.  B  F 

3.7  Rapid  deceleration 

(no  stop).  B  F 

3.8  Gradual  deceleration.  B  F 

3.9  Sudden  stop.  B  F 


3.10  Maintain  constant  speed.  B  F 


VEHICLE  MANEUVERING— HELICOPTERS 

1.  Perform  takeoff  to  hover. 

2.  Perform  Instrunent  takeoff. 

3.  Perform  hover  checks. 

4.  Perform  hovering  turns. 


VEHICLE  MANEUVERING— HELICOPTERS 

(Continued) 

5.  Perform  hovering  flight. 

6.  Perform  normal  takeoff. 

7.  Perform  maximum  perfor¬ 
mance  takeoff. 

8.  Perform  straight  and  level 
flight. 

9.  Perform  climbs  and  descents. 

10.  Perform  turns. 

11.  Perform  instrument  turns. 

12.  Perform  acceleration/decel¬ 
eration. 

13.  Perform  traffic  pattern 
flight. 

14.  Perform  high  speed  flight. 

15.  Perform  hovering  autorota¬ 
tion. 

16.  Perform  standard  autorota¬ 
tion. 

17.  Perform  standard  autorota¬ 
tion  with  turn. 

18.  Perform  holding  procedures. 

19.  Perform  unusual  attitude 
recovery . 

20.  Perform  before- landing 
check. 

21.  Perform  shallow  approach  to 
a  running  landing. 

22.  Perform  landing  from  hover. 

23.  Perform  normal  landing 
approach. 

24.  Perform  shallow  landing 
approach. 

25.  Perform  steep  landing 
approach. 

26.  Perform  Instrument  approach. 

27.  Perform  GCA  approach. 

28.  Perform  IFR  helicopter  re¬ 
covery  procedure. 

29.  Perform  tactical  instrument 
approach. 

30.  Perform  go-around. 


VEHICLE  LOADING/UNLOADING 

1.  Load  and  position  cargo/ 
passengers  In/on  vehicle. 
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OPERATIONS  TASKS 


TARGET  INFORMATION  GATHERING  AND 

INTERPRETATION  (Continued) 

7.  Identify  target. 

8.  Determine  nunber  of  targets. 

9.  Determine  target  location/ 
range. 

10.  Determine  target  speed. 

11.  Determine  target  direction. 

12.  Determine  target  formation/ 
tactical  situation. 

13.  Select  and  order  targets 
based  on  the  matching  of 
priorities  with  target  in¬ 
formation  gathered. 

14.  Recognize  countermeasures  and 
take  appropriate  action. 


VEHICLE  MANEUVERING— GROUND 
VEHICLES 


1. 

Observe  environment  for  ob- 

stacles,  landmarks,  etc. 

2. 

Read  and  use  Instruments 

appropriate  to  vehicle  ma- 

neuvering. 

3. 

Perform  the  following,  mov¬ 

ing  backward  (B)  and/or  for- 

ward  (f).  Circle  B  or  F 

as 

appropriate. 

3.1 

Tight  turn. 

B 

F 

3,2 

Wide  turn. 

B 

F 

3.3 

Accelerating  turn. 

B 

F 

3.4 

Decelerating  turn. 

B 

F 

3.5 

Rapid  acceleration. 

B 

F 

3.6 

Gradual  acceleration. 

B 

F 

3.7 

Rapid  deceleration 

(no  stop). 

B 

F 

3.8 

Gradual  deceleration. 

B 

F 

3.9 

Sudden  stop. 

B 

F 

3.10  Maintain  constant  speed. 

B 

F 

VEHICLE  MANEUVERING— HELICOPTERS 

1.  Perform  takeoff  to  hover. 

2.  Perform  Instrument  takeoff. 

3.  Perform  hover  checks. 

4.  Perform  hovering  turns. 


VEHICLE  MANEUVERING— HELICOPTERS 

(Continued) 

5.  Perform  hovering  flight. 

6.  Perform  normal  takeoff. 

7.  Perform  maximum  perfor¬ 
mance  takeoff. 

8.  Perform  straight  and  level 
flight. 

9.  Perform  climbs  and  descents. 

10.  Perform  turns. 

11.  Perform  instrument  turns. 

12.  Perform  acceleration/decel¬ 
eration. 

13.  Perform  traffic  pattern 
flight. 

14.  Perform  high  speed  flight. 

15.  Perform  hovering  autorota- 
ti  on . 

16.  Perform  standard  autorota¬ 
tion. 

17.  Perform  standard  autorota¬ 
tion  with  turn. 

18.  Perform  holding  procedures. 

19.  Perform  unusual  attitude 
recovery. 

20.  Perform  before- landing 
check. 

21.  Perform  shallow  approach  to 
a  running  landing. 

22.  Perform  landing  from  hover. 

23.  Perform  normal  landing 
approach. 

24.  Perform  shallow  landing 
approach. 

25.  Perform  steep  landing 
approach. 

26.  Perform  Instrument  approach. 

27.  Perform  GCA  approach. 

28.  Perform  IFR  helicopter  re¬ 
covery  procedure. 

29.  Perform  tactical  instrument 
approach. 

30.  Perform  go-around. 


VEHICLE  LOADING/UNLOADING 

1.  Load  and  position  cargo/ 
passengers  in/on  vehicle. 


V./-A  -  1  6 


OPERATIONS  TASKS 


WEAPON  DELIVERY-MINES 

1.  Select  appropriate  location 
for  mine  installation. 

2.  Inspect  mine/ triggering  device/ 
fusing  device. 

3.  Transport  mine. 

4.  Prepare  mine  for  installation. 

5.  Install  mine  (including  the 
digging  of  a  hole). 

6.  Camouflage  mine/triggering 
device. 

7.  Aim  mine,  if  applicable. 

8.  Test  circuit(s). 

9.  Arm  mine. 

10.  Fire  mine,  if  applicable. 

11.  Disarm  mine. 


WEAPON  FUNCTION  MANAGEMENT 

1.  Determine  type  of  target. 

2.  Determine  speed/direction  of 
target. 

3.  Determine  target  range  at 
time  of  weapon  delivery. 

4.  Determine  weather  conditions 
which  impact  weapon  delivery 
and  adjust  for  them. 

5.  Determine  type  of  ammunition 
to  be  used  based  on  all  above 
factors. 

6.  Determine  probable  amount  of 
ammunition  required  to  kill 
target  under  existing/pro¬ 
jected  conditions. 

7.  Reconmend  action  based  on  avail¬ 
able  supply  of  annunition, 
future  probable  requirements 
for  amnunition,  and  probable 
required  amount  to  kill  target 
at  various  ranges/speeds. 
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OPERATIONS  TASKS 


WEAPON  DELIVERY-MINES 

1.  Select  appropriate  location 
for  mine  Installation. 

2.  Inspect  mine/triggering  device/ 
fusing  device. 

3.  Transport  mine. 

4.  Prepare  mine  for  installation. 

5.  Install  mine  (Including  the 
digging  of  a  hole). 

6.  Camouflage  mine/triggering 
device. 

7.  Aim  mine.  If  applicable. 

8.  Test,  circuit(s). 

9.  Arm  mine. 

10.  Fire  mine,  if  applicable. 

11.  Disarm  mine. 


WEAPON  FUNCTION  MANAGEMENT 

1.  Determine  type  of  target. 

2.  Determine  speed/direction  of 
target. 

3.  Determine  target  range  at 
time  of  weapon  delivery. 

4.  Determine  weather  conditions 
which  impact  weapon  delivery 
and  adjust  for  them. 

5.  Determine  type  of  ammunition 
to  be  used  based  on  all  above 
factors. 

6.  Determine  probable  amount  of 
ammunition  required  to  kill 
target  under  existing/pro¬ 
jected  conditions. 

7.  Reconmend  action  based  on  avail¬ 
able  supply  of  ammunition, 
future  probable  requirements 
for  ammunition,  and  probable 
required  amount  to  kill  target 
at  various  ranges/speeds. 
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MAINTENANCE  TASKS 


For  each  system  function  there  are  maintenance  tasks.  Maintenance 
tasks  are  performed  by  system  operators  and  malntalners  and  are  categorized 
as  scheduled  and  unscheduled.  Maintenance  tasks  consist  of  an  action  at¬ 
tached  to  an  appropriate  object.  For  each  system  function  the  following 
action  segments  of  maintenance  task  templates  should  be  used  to  state  the 
appropriate  maintenance  tasks. 


1. 

Inspect 

2. 

Lubricate 

3. 

Fill 

4. 

Drain 

5. 

Purge 

6. 

Paint 

7. 

Clean 

8. 

Change/Replace 

9. 

T  roubl eshoot/Di agnose 

10. 

Remove 

11. 

Disassemble 

12. 

Assemble 

13. 

Install 

14. 

Ad just/ Align 

15. 

Test 
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CONDITIONS 


OPERATIONAL:  CREW 

1.  With  optimun  crew  (specify). 

2.  With  normal  operational  crew 
(specify). 

3.  With  minimtm  crew  (specify). 


OPERATIONAL:  HARDWARE 

1.  With  hardware  fully 
operational. 

2.  With  partial  breakdown 
(specify). 

3.  With  hardware  fully  down. 


OPERATIONAL:  INFORMATION  INPUTS 

1.  With  full  information  inputs. 

2.  With  partial  information 
inputs  (specify). 

3.  With  no  information  inputs. 


PERSONNEL:  APTITUDES 

1.  With  personnel  with  minimum 
applicable  aptitudes  (specify). 

2.  With  personnel  with  normal 
applicable  aptitudes  (specify). 

3.  With  personnel  with  optimun 
applicable  aptitudes  (specify). 


PERSONNEL:  DURATION  OF  PRECEEDING 
WORK 

1.  Following  no  work. 

2.  Following  an  extended  period  of 
work  (specify). 

3.  Following  a  normal  period  of 
work  (specify). 


PERSONNEL:  EXPERIENCE 

1.  With  personnel  with  minimun 
experience  (specify). 

2.  With  personnel  with  normal 
experience  (specify). 


PERSONNEL:  EXPERIENCE  (Continued) 

3.  With  personnel  with  optimum 
experience  (specify). 


PERSONNEL:  PERCEPTUAL  ABILITY 

1.  With  personnel  with  minimal 
perceptual  abilities 
(specify). 

2.  With  personnel  with  normal 
perceptual  abilities 
(specify). 

3.  With  personnel  with  optimun 
perceptual  abilities 
(specify). 


PERSONNEL:  PHYSICAL  SIZE 

1.  With  personnel  of  minimum 
size  (specify). 

2.  With  personnel  of  normal 
size  (specify). 

3.  With  personnel  of  maximum 
size  (specify). 


PERSONNEL:  PHYSICAL  STRENGTH 

1.  With  personnel  with  minimum 
strength. 

2.  With  personnel  with  normal 
strength. 

3.  With  personnel  with  optimum 
strength. 


PERSONNEL:  PROTECTIVE  GEAR 

1.  While  wearing  applicable 
protective  clothing/qear 
(specify). 

2.  While  wearing  normal  cloth 
ing/gear  (specify). 
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CONDITIONS 


OPERATIONAL:  CREW 

1.  With  optimum  crew  (specify). 

2.  With  normal  operational  crew 
(specify). 

3.  With  minimtm  crew  (specify). 


OPERATIONAL:  HARDWARE 

1.  With  hardware  fully 
operational . 

2.  With  partial  breakdown 
(specify). 

3.  With  hardware  fully  down. 


OPERATIONAL:  INFORMATION  INPUTS 

1.  With  full  information  inputs. 

2.  With  partial  information 
inputs  (specify). 

3.  With  no  information  inputs. 


PERSONNEL:  APTITUDES 

1.  With  personnel  with  minimun 
applicable  aptitudes  (specify). 

2.  With  personnel  with  normal 
applicable  aptitudes  (specify). 

3.  With  personnel  with  optimun 
applicable  aptitudes  (specify). 


PERSONNEL:  DURATION  OF  PRECEEDING 
WORK 

1.  Following  no  work. 

2.  Following  an  extended  period  of 
work  (specify). 

3.  Following  a  normal  period  of 
work  (specify). 


PERSONNEL:  EXPERIENCE 

1.  With  personnel  with  minimun 
experience  (specify). 

2.  With  personnel  with  normal 
experience  (specify). 


PERSONNEL:  EXPERIENCE  (Continued) 

3.  With  personnel  with  optimum 
experience  (specify). 


PERSONNEL:  PERCEPTUAL  ABILITY 

1.  With  personnel  with  minimal 
perceptual  abilities 
(specify). 

2.  With  personnel  with  normal 
perceptual  abilities 
(specify). 

3.  With  personnel  with  optimun 
perceptual  abilities 
(specify). 


PERSONNEL:  PHYSICAL  SIZE 

1.  With  personnel  of  minimun 
size  (specify). 

2.  With  personnel  of  normal 
size  (specify). 

3.  With  personnel  of  maximum 
size  (specify). 


PERSONNEL:  PHYSICAL  STRENGTH 

1.  With  personnel  with  minimum 
strength. 

2.  With  personnel  with  normal 
strength. 

3.  With  personnel  with  optimum 
strength. 


PERSONNEL:  PROTECTIVE  GEAR 

1.  While  wearing  applicable 
protective  clothing/qear 
(specify). 

2.  While  wearing  normal  cloth¬ 
ing/gear  (specify). 
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CONDITIONS 


TARGET :  DIRECTION  OF  MOTION 

1.  Closing  (specify  angle). 

2.  Retreating  (specify  angle). 

3.  Crossing  (specify  direction). 

4.  Complex  maneuver  (specify). 


TARGET:  LOCATION 

1.  Minimtm  range  (specify). 

2.  Maximun  range  (specify). 

3.  Normal  range  (specify). 

4.  Azimuth  and  elevation  of 
target  (specify). 


TARGET:  NUMBER 

1.  Single  target. 

2.  Multiple  simultaneous  targets 
(specify). 

3.  Multiple  sequential  targets 
(specify). 

4.  Combination  of  multiple 
simultaneous  and  multiple 
sequential  targets  (specify). 

5.  Noise  -  nunber/%  of  targets 
within  nontarget  background 
(specify). 


TARGET:  TYPE 

1.  Specify  by  type  or  size. 


TARGET:  SPEED 

1.  Maximum  speed  (specify). 

2.  Minlmun  speed  (specify). 

3.  Cruising  speed  (specify). 

4.  Radical  alterations  of  speed 
(specify). 

5.  Stationary. 


TERRAIN:  GROUND  SLOPE 

1.  Flat. 

2.  Low  positive  hilly  (specify). 

3.  Low  negative  hilly  (specify). 

4.  High  positive  mountainous 
(specify). 

5.  High  negative  mountainous 
(specify). 


TERRAIN:  GROUND  SURFACE 

1.  Sandy. 

2.  Rocky. 

3.  Loam  (deep  soil). 

4.  Paved  (specify  type  and 
carrying  level). 

5.  Broken  paved. 

6.  Broken  ground. 

7.  Plowed  fields. 

8.  Bare  packed. 

9.  Vegetation  covered. 


TERRAIN:  GROUND  AND  WATER  SURFACE 

1.  Light  mud. 

2.  Heavy  mud. 

3.  Dry. 

4.  Water  covered. 

5.  Ice  covered. 

6.  Snow  covered. 


TERRAIN:  OBSTACLES 

1.  Dense  vegetation. 

2.  Light  vegetation. 

3.  Hedge  rows. 

4.  Rivers  (specify  depth, 
width). 

5.  Manmade  structures  (specify). 

6.  Traps  (specify). 

7.  No  obstacles. 
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CONDITIONS 


TARGET:  DIRECTION  OF  MOTION 

1.  Closing  (specify  angle). 

2.  Retreating  (specify  angle). 

3.  Crossing  (specify  direction). 

4.  Complex  maneuver  (specify). 


TARGET:  LOCATION 

1.  Minimun  range  (specify). 

2.  Maximun  range  (specify). 

3.  Normal  range  (specify). 

4.  Azimuth  and  elevation  of 
target  (specify). 


TARGET:  NUMBER 

1.  Single  target. 

2.  Multiple  simultaneous  targets 
(specify). 

3.  Multiple  sequential  targets 
(specify). 

4.  Combination  of  multiple 
simultaneous  and  multiple 
sequential  targets  (specify). 

5.  Noise  -  mmber/X  of  targets 
within  nontarget  background 
(specify). 


TARGET:  TYPE 

1.  Specify  by  type  or  size. 


TARGET:  SPEED 

1.  Maximun  speed  (specify). 

2.  Minimum  speed  (specify). 

3.  Cruising  speed  (specify). 

4.  Radical  alterations  of  speed 
(specify). 

5.  Stationary. 


TERRAIN:  GROUND  SLOPE 

1.  Flat. 

2.  Low  positive  hilly  (specify). 

3.  Low  negative  hilly  (specify). 

4.  High  positive  mountainous 
(specify). 

5.  High  negative  mountainous 
(specify). 


TERRAIN:  GROUND  SURFACE 

1.  Sandy. 

2.  Rocky. 

3.  Loam  (deep  soil). 

4.  Paved  (specify  type  and 
carrying  level). 

5.  Broken  paved. 

6.  Broken  ground. 

7.  Plowed  fields. 

8.  Bare  packed. 

9.  Vegetation  covered. 


TERRAIN:  GROUND  AND  WATER  SURFACE 

1.  Light  mud. 

2.  Heavy  mud. 

3.  Dry. 

4.  Water  covered. 

5.  Ice  covered. 

6.  Snow  covered. 


TERRAIN:  OBSTACLES 

1.  Dense  vegetation. 

2.  Light  vegetation. 

3.  Hedge  rows. 

4.  Rivers  (specify  depth, 
width) . 

5.  Manmade  structures  (specify). 

6.  Traps  (specify). 

7.  No  obstacles. 
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MAINTENANCE  TASKS 


For  each  system  function  there  are  maintenance  tasks.  Maintenance 
tasks  are  performed  by  system  operators  and  malntalners  and  are  categorized 
as  scheduled  and  unscheduled.  Maintenance  tasks  consist  of  an  action  at¬ 
tached  to  an  appropriate  object.  For  each  system  function  the  following 
action  segments  of  maintenance  task  templates  should  be  used  to  state  the 
appropriate  maintenance  tasks. 


1. 

Inspect 

2. 

Lubricate 

3. 

Fill 

4. 

Drain 

5. 

Purge 

6. 

Paint 

7. 

Clean 

8. 

Chanqe/Replace 

9. 

T  roubl eshoot/Di agnose 

10. 

Remove 

11. 

Disassemble 

12. 

Assemble 

13. 

Install 

14. 

Adjust/Align 

15. 

Test 
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Part  1.  Description 


A.  Mission 

1.  Heavy  division,  separate  ar sored/ Mechanised  brigade  and  araored 
cavalry  regiaent  HIP  battalions  are  organised,  aanned  and  equipped  to  perfora 
the  Direct  Support  mission  as  well  as  the  other  Field  Artillery  standard 
tactical  missions  of  Reinforcing,  General  Support  Reinforcing,  General  Support 
and  nonstandard  tactical  missions.  Other  HIP  equipped  battalions  can  perfora 
all  standard  tactical  missions  except  Direct  Support  without  augmentation. 

2.  HIP  battalions  will  predominantly  provide  dose  support  fires 
against  targets  posing  a  threat  to  the  committed  brigades.  Additionally, 
close  support  fires  will  be  provided  for  rear  area  combat  operations,  and  long 
range  fires  will  be  used  to  augaent  other  fire  support  systeas  In  attacking 
threat  forces  before  they  can  Influence  the  battle.  The  HIP  will  fire  both 
conventional  and  nuclear  munitions  and  will  be  coapatible  with  all  fielded  and 
developaental  155mm  munitions  and  propelling  charges.  HIP  type  units  will 
also  be  in  Corps  Artillery  where  they  will  augment  the  fires  of  divisional/ 
brigade  field  artillery  units. 

3.  The  HIP  must  be  capable  of  worldwide  deployment  with  heavy  US 
forces,  and  suitable  for  the  most  extreme  rigors  of  land  coabat  in  the  1990- 
2010  timeframe.  The  most  severe  test  of  US  Aray  capabilities  la  expected  to 
continue  to  be  one  of  opposing  Warsaw  Pacr  invasion  of  Geraany.  Coabat  there 
would  be  doalnated  by  highly  mobile,  heavily  araored  maneuver  forces  supported 
by  massive  amounts  of  cannon  and  rocket  artillery  and  close  support  aircraft. 
In  the  opening  phases  of  combat  the  threat  would  use  both  conventional  and 
toxic  chemical  and  possibly  biological  weapons,  as  the  Warsaw  Pact  attacks 
behind  the  Forward  Line  of  Troops  and  concentrates  on  the  destruction  of 
US/NATO  nuclear  capability  in  preparation  for  the  nuclear  phase  of  the  con¬ 
flict.  The  Warsaw  Pact  forces  would  be  numerically  superior  to  the  US/NATO 
forces,  with  near  technological  parity.  Force  ratios  would  drive  the  direct 
fire  fight  In  their  favor  If  effective  fire  support  were  not  available. 

A.  The  HIP  must  possess  sufficient  mobility  to  accompany  its 
supported  maneuver  forces,  and  be  available  in  sufficient  numbers  to  provide 
responsive,  effective  fires  throughout  the  supported  commander's  area  of 
Influence.  The  Warsaw  Pact  forces  will  be  attempting  to  find  and  destroy  the 
HIP  as  one  of  the  highest  priorities  In  the  breakthrough  tone. 

S.  The  Heavy  Brlgade/Dl vision  Field  Artillery  Fire  Support  Weapon 
System  Mission  Eleaent  Need  Statement  (MENS),  approved  in  Dec  60,  identified 
four  major  deficient  areas  In  the  current  Division  Support  Weapon  System: 

••  Responsiveness:  the  ability  to  rapidly  deliver  and  sustain 
massed  firepower  on  the  target. 
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b.  Survivability:  the  ability  of  the  weapon  system,  Its  ammuni¬ 
tion  and  crew  to  withstand  counterfire,  nines,  electromagnetic  effects,  and 
air,  ground,  and  nuclear,  biological,  and  chemical  (NBC)  attack.  This  in¬ 
cludes  operations  in  a  contaalnated  area  and  In  areas  subjected  to  Nuclear 
Veapons  Effects  (NWE). 

c.  Teralnal  Effects:  the  ability  to  achieve  the  desired  attack 
criteria  (destruction/neutrallzatlon/suppression)  against  enemy  elements  in 
the  full  spectrum  of  battlefield  environments. 

d.  Reliability,  Availability.  Maintainability  and  Durability 
RAM-D):  the  operational  performance  of  the  weapon  system  in  terms  of  failure 
rates,  time  required  for  repairs,  and  maintenance  downtime. 

6.  The  DSWS  SSC  has  analyzed  M109A2/A3/A3E1  deficiencies  and  has 
determined  the  functional  characteristics  of  HIP  required  to  remedy  these 
deficiencies.  Command  reviews  have  prioritized  these  characteristics  for  a 
aid-term  interim  system,  which  have  been  set  forth  In  the  LOA  for  HIP. 

B.  System.  The  HIP  consists  of  a  155mm  Self-Propelled  Howitzer  (SPH), 
its  Integrated  Logistics  Support  (ILS),  and  command,  control  and  communica¬ 
tions  (C5)  interface  with  the  artillery  fire  support  system.  The  SPH  Is  a 
product  Improvement  of  the  M109A2/A3. 

1.  System  Description. 

a.  Self-Propelled  Howitzer  (SPH): 

(1)  The  HIP  SPH,  designated  the  M109A3E2,  is  an  armored, 
fully  tracked  howitzer  carrying  34  complete  conventional  geometry  rounds  and 
two  oversized  projectiles  on  board.  It  is  operated  by  a  nominal  crew  of  five. 
Including  the  driver.  Its  main  armament  consists  of  a  modified  version  of  the 
M185  Cannon  Assembly  (the  XM284)  and  M178  Cun  Mount  (the  XM182)  currently 
employed  on  the  M109A2/A3/A3E1.  All  current,  as  well  as  developmental,  US 
conventional  155mm  artillery  projectiles  will  be  system  compatible.  The 
cannon,  propelling  charge,  and  projectile  mix  will  permit  unassisted  ranges  of 
at  least  22  km  and  a  maximum  assisted  range  of  at  least  30  km.  In  addition, 
as  a  parallel  R&D  effort,  the  VCSA  has  directed  that  an  armament  system 
consisting  of  a  new  39  caliber  cannon  (the  XM283)  and  a  modular  redundant 
component  gun  mount  (the  XM183),  and  a  cannon  which  extends  the  range  capabil¬ 
ity  beyond  30  km  (the  XM282)  be  developed  and  investigated  during  HIP. 

(2)  The  fire  control  system  will  be  fully  automated,  providing 
accurate  position  location  and  azimuth  reference,  onboard  ballistic  solutions 

of  fire  missions  (with  external  backup),  and  computer  controlled  gun  drive 
through  servos  with  manual  backup.  These  Improvements  will  permit  flexibility 
(emplacement  times  will  be  less  than  60  seconds)  and  accommodate  high  firing 
rates.  The  emplaced  SPH  will  be  able  to  fire  within  30  seconds.  Digital  and 
voice  communications  util  zing  current  systems  and  the  Single  Channel  Ground/ Air 
Radio  System  (SINCGARS),  will  enable  dispersed  operations/missiens  from  one 
firing  unit  to  multiple  battalions.  Tactical  and  technical  fire  control  and 
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direction  will  be  maintained  through  an  Interface  with  a  Battery  Computer 
System  (BCS),  end  Advanced  Field  Artillery  Tactical  Data  System 

(AFATDS).  The  SPH  will  also  fully  incorporate  state-of-the-art  materials  and 
technologies  to  achieve  maximised  availability  and  maintainability  through  the 
use  of  Built-in-Test  Equipment  (BITE),  both  diagnostic  and  prognostic; 
modularity;  redundancy;  reduced  operating  stress  levels  and  enhanced  component 
and  ballistic  protection  for  the  crew  and  vital  equipment.  All  product  Im¬ 
proved  equipment  will  also  be  hardened  to  withstand  Nuclear  Weapons  Effects 
(NVE). 


(3)  The  HIP  SPH  equipped  with  the  new  39  caliber  cannon  and 
new  gun  mount  is  designated  the  M109A3E3  howitzer. 

b.  Interface  with  Fire  Support:  The  HIP  will  have  the 
capability  to  Interact  with  the  command,  control,  and  communication  of  the 
artillery  fire  support  system.  It  shall  be  able  to  communicate  with  the  fire 
support  element,  whether  it  is  a  battlion/brlgade  fire  support  section  (FSS), 
battalion  Operations/Intelligence  Section,  target  acquisition  (e.g.,  ATHS, 
FIREFINDER,  RPV,  FIST,  FO)  or  a  battalion  or  platoon  fire  direction  center, 
using  AFATDS,  BCS,  ang  SINCGARS  communication  equipment. 

2.  Interfaces.  The  HIP  must  be  compatible  with: 

a.  Ammunition:  All  US  standard  and  developmental  155mm 
ammunition,  to  Include  fuzes,  projectiles,  propelling  charges,  primers  (except 
KK2A4),  and  their  packaging. 

b.  C3  Elements:  SINCGARS  Communication  Equipment, 

AFATDS,  ATHS,  BCS,  FIREF1NDER,  RPV,  FIST  DMD,  and  FO  DMD. 

c.  Integrated  Logistics  Support  (ILS)  Elements:  Design  influence 
and  integration  to  Include  logistic  related  reliability  and  malntalnabllllty; 
maintenance  plan;  supply  support;  support  equipment  and  TMDE  to  include 
Built-In  Test  (BlT)/Built-ln  Test  Equipment  (BITE);  technical  data;  computer 
resources  support;  packaging,  handling  and  storage;  transportation  and 
transportability;  facilities;  standardization  and  interoperability;  and 
MANPR1NT  to  Include  manpower  and  personnel,  training  and  training  devices,  and 
safety,  health  and  hman  factors. 

d.  Ammunition  Resupply  Vehicle:  M992  FAA5V  and  M548  ARV. 

C.  Required  Operational  Characteristics.  The  HIP  required  operational 
characteristics  are  addressed  in  the  HIP  Letter  of  Agreement  and  in  the  HIP 
Operational  and  Organizational  (0&0)  Plan.  The  KIP  has  the  traditional 
artillery  characteristics  of  shoot,  move,  communicate,  and  survive,  but  does 
them  in  such  sn  effective  manner  so  as  to  optimize  responsiveness,  terminal 
effects,  survivability,  and  reliability,  availability  and  maintainability  (RAM); 
thus  Increasing  the  combat  multiplier  by  giving  the  effect  of  having  more 
cannons  on  the  battlefield.  Required  operational  characteristics  are  reflected 
In  the  criteria  of  Part  I,  Paragraph  E.  of  this  TEMP. 
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D.  Required  Technical  Characteristics.  Most  HIP  required  technical  char¬ 
acteristics  are  expressed  in  terms  of  operational  performance  thresholda  and 
are  listed  in  the  HIP  System  Specification.  Subordinate  technical  characteris¬ 
tics  not  so  expressed  will  be  derived  by  tt>e  development  contractor  using  the 
system  engineering  process. 

E.  HIP  Issues  and  Criteria.  The  following  Issues  and  Criteria  have  been 
developed  by  the  TRADOC  System  Manager  -  Cannon  for  the  M109  155mm  SP  HIP. 

After  staffing  with  the  agencies  specified  In  TRADOC  Reg  71-9  they  will  be 
presented  to  the  TRADOC  Materiel  Evaluation  Committee's  Senior  Advisory 
Council  for  approval  prior  to  submission  to  AMC  and  HQ,  DA.  Those  Issues  that 
are  considered  critical  and  must  be  addressed  before  proceeding  from  one  phase 
of  development  to  the  next  are  denoted  by  an  asterisk.  The  criteria  below 
reflect  requirements  based  upon  analysis  of  SCORES  Europe  I,  Sequence  1IA; 
modifications  to  certain  of  these  criteria  may  be  necessary  when  analysis  of 
SCORES  Europe  V  is  complete.  As  independent  evaluation  plans  are  developed,  a 
data  source  matrix  will  be  finalized.  OT  II  will  confirm  that  the  "HlP 
battalion's  operational  concept  can  be  executed  by  representative  soldiers 
using  prototype  equipment  while  In  a  tactical  environment  based  on  the  SCORES, 
Europe  V  scenario.  The  test  unit  will  employ  the  HIP  O&O  Plan  under  the 
conditions  specified  in  the  Operational  Mode  Summary/ Mission  Profile  (OMS/MP). 

DT  II  will  demonstrate  that  developmental  engineering  objectives  required  to 
support  operational  objectives  are  met.  The  criteria  below  apply  when  the  HIP 
howitzer  is  equipped  with  the  modified  M185/M178  armament  package  (M109A3E2) 
and  is  operational.  Modifications  and  changes  to  the  criteria  when  the  HIP 
howitzer  is  equipped  with  an  alternative  armament  package  (M109A3E3)  are 
contained  in  Annex  B.  RAM  failures  will  be  scored  IAW  the  procedures  speci¬ 
fied  in  the  RAM  Annex  of  the  HIP  LOA. 

1.  Mission  Performance, 
a.  *Iesue  1. 

Is  the  fire  support  provided  by  the  HIP  howitzer  responsive? 

Scope.  The  tactical  scenario  will  require  the  HIP  howitzers, 
and  crews,  to  provide  fire  support  for  maneuver  forces  IAW  the  conditions 
specified  in  the  OMS/MP  for  twenty-four  hour  wartime  weighted  average  periods. 

The  howitzer  and  crews'  capability  for  firing  while  emplaced  and  for  responding 
to  calls  for  fire  while  moving  will  be  evaluated.  Operations  will  be  conducted 
in  varied  terrain  conditions.  The  HIP  howitzer  will  be  employed  in  both  open 
and  closed  configurations  and  in  its  bsckup,  manual  mode  of  operations  for 
emplacement,  lay  and  firing.  The  HIP  howitzer  will  respond  to  calls  for  fire 
from  target  acquisition  sources  as  well  ss  fire  commands/ordcrs  from  fire  direction 
centers.  These  capabilities  will  be  evaluated  during  periods  of  reduced 
visibility  (day  and  night)  and  while  the  crew  is  In  various  NBC  mission-oriented 
protective  postures  (MOPP),  up  to  and  including  MOPP  IV.  Normally  the  ammuni¬ 
tion  fired  will  be  stowed  on-board  the  howitzer  in  an  unpackaged,  ready 
configuration  (projectiles  fuzed  in  ammunition  racks,  propelling  charges 
stored  in  the  it  packing  containers). 
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(2)  Criteria 


(a)  Upon  receiving  a  call  for  fire  froa  a  FA  target  ac¬ 
quisition  source  (f ire-for-ef feet  missions  only)  or  fire  eoaaands  froa  a  fire 
direction  center,  the  aedian  tlae  for  an  enplaced  HIP  howitzer  to  fire  the 
Initial  round  of  the  mission  Bust  be  less  than  30  seconds  (45  seconds  for 
high  angle  missions). 

(b)  Upon  receiving  a  fire  mission  from  an  FA  target  acqulsltl 
source  (f  ire-for-ef  feet  missions  only)  or  fire  eoaaands  from  a  fire  direction 
center,  the  median  time  for  a  moving  HIP  howitzer  to  stop  and  fire  the  initial 
round  of  the  mission  must  be  less  than  60  seconds  (75  seconds  for  high  angle 
missions) . 


(c)  An  enplaced  HIP  howitzer  must  demonstrate  the  capa¬ 
bility  to  fire  one  oversized  projectile  (e.g.,  54  inch  Copperhead  round)  In  a 
aedian  time  of  less  than  40  seconds  after  receiving  fire  commands. 

(d)  Vhen  emplacing,  laying,  and  firing  in  its  backup,  manual 
mode  of  operations,  the  HIP  howitzer  crew  must  equal  or  exceed  the  standards  for 
the  M109A2/A3  prescribed  in  ARTEP  6-100. 

(3)  Rationale.  To  respond  to  the  maneuver  forces'  demands 
for  close,  continuous,  and  effective  fire  support,  HIP  howitzer  units  must 
demonstrate  their  capabilities  for  emplacing  and  rapidly  firing  one  or  more 
fire  missions. 

(4)  Source.  Letter  of  Agreement  (LOA),  para.  3c(3),  3d(l),  3e(l); 
ARTEP  6-100,  The  Field  Artillery  Cannon  Battery. 

b .  *Issue  2.  Is  the  firepower  provided  by  the  HIP  howitzer  effective? 

(1)  Scope.  The  tactical  scenario  will  stress  the  howitzer  and 
crews'  capability  for  providing  the  volume  of  fire  required  during  operations 
conducted  1AV  the  0MS/MP  twenty-four  hour  wartime  weighted-average  periods. 

The  SCORES  Europe  I,  Sequence  IIA  0MS  weighted  average  for  firepower  is 
equivalent  to  73  missions  and  301  rounds  per  howitzer  per  day.  The 
rate  of  fire  achieved  using  the  mechanical  loader  aaslst  (If  included  as  part  of 
HIP  modifications)  will  be  compared  with  the  rate  of  fire  achieved  In  the 
manual- loading  mode  and  with  the  rate  of  fire  of  the  M109A3E1  (HELP)  howitzer. 
Ammunition  fired  for  rate-of-flre  testing  normally  will  be  stowed  on  board  the 
howitzer  in  an  unpackaged,  ready  configuration  (projectiles  fuzed  in  ammo  racks, 
propelling  charges  stored  in  their  packing  containers).  The  sustained  rate  of 
fire  for  a  HIP  howitzer  employed  with  an  FA  ammunition  support  vehicle  (FAASV) 
and  with  the  M548  will  be  evaluated.  The  accuracy  of  the  automated  on  board 
position  location  system,  gun  pointing  (gun  drive  servos)  and  technical  fire 
control  systems  will  be  recorded  and  reported.  The  rate  of  fire  for  high-angle 
missions  may  be  reduced  by  the  tlae  required  to  elevate  the  cannon  above  the 
maximum  loading  elevation  (TBD  by  DT  testing).  Data  on  firing  accuracies 
measured  at  the  point  of  Impact  will  be  collected  and  reported.  These 
capabilities  will  be  evaluated  during  periods  of  reduced  visibility, 
under  varied  terrain  conditions,  during  day  and  night  operations,  and  in 
various  NBC  mission-oriented  protective  postures,  up  to  and  including  M0PP  IV. 
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(2)  Criteria 


(a)  The  HIP  howitzer  (In  a  fully  operational  status)  and  crew 
aust  be  capable  of  firing  301  rounds  per  tube  per  day. 

(b)  The  HIP  howitzer  and  crew  aust  equal  or  exceed  a  maximum 
firing  rate  of  6  rounds  per  ainute  for  low-angle  fire,  if  the  howitzer  Is 
equipped  with  a  mechanical  loader  assist;  otherwise,  four  rounds  per  alnute  for 
low-angle  fire. 


(c)  The  firing  accuracy  of  the  HIP  howitzer  fire  control 
systea  aust  equal  or  exceed  the  accuracy  achieved  by  the  M109A2/A3  fire  control 
system. 


(d)  The  precision  probable  error  in  range  for  the  howitzer's 
araaaent  systea  when  firing  unassisted  projectiles  will  be  0.25Z  of  range  and 
for  assisted  projectiles  0.30Z  of  range.  The  precision  probable  error  in 
deflection  will  be  1  mil. 

(e)  The  howitzer's  araaaent  systea  will  achieve  an  unassisted 
maximum  range  of  greater  than  or  equal  to  22  ka,  an  assisted  maximum  range  of 
greater  than  or  equal  to  30  km,  and  a  minimum  range  for  hlgh-angle  fire  of  less 
than  or  equal  to  4  km. 

(f)  The  on-board  ballistic  computer  solutions  and  the  BRL 
standard  (BCS)  solutions  aust  compare  to  within  0.03Z  of  range  or  5  meters, 
whichever  is  greater. 

(3)  Rationale.  The  required  volume  of  firepower  Is  specified  in 
the  HIP  operational  mode  summary/aission  profile  and  is  dependent  upon  the 
howitzer  being  fully  operational.  If  the  howitzer  is  equipped  with  a  mechanical 
loader  assist,  the  Increased  rate  of  fire  will  enable  the  howitzer  to  provide 
the  required  firepower  and  creates  the  effect  of  having  additional  tubes  on  the 
battlefield.  Measurement  of  fire  mission  accuracy  standards  In  an  operational 
environment  are  explained  In  ARTEP  6-100,  The  Pield  Artillery  Cannon  Battery. 
Increasing  the  howitzer's  assisted  range  to  30+  km  will  enable  the  HIP  to  attack 
the  majority  (approximately  95Z  per  FA  Simulation  Two-Sided  (FAST)  analysis)  of 
the  targets  available. 

(A)  Source.  LOA,  para  3d(l),  (3),  (S),  and  3e(l);  Annex  A,  para 
Af(4)(b);  ARTEP  6-100,  Appendix  E.  Precision  requirements,  USAFAS,  BRL. 

c.  *Issue  3.  Is  the  HIP  howitzer's  external  and  Internal  command, 
control,  and  communications  system  effective? 

(1)  Scope.  The  capabilities  of  the  howitzer's  internal  and 
external  communications  systems  for  providing  digital  and  voice  communications 
during  tactical  operations  will  be  evaluated.  The  tactical  scenario  will  be 
based  on  the  SCORES,  Europe  V  scenario  and  will  stress  the  unit's  command, 
control,  and  communications  capability  for  operating  the  HIP  howitzer  during 
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twenty-four  hour,  OHS/HP  wartime  weighted-average  periods.  Fire  missions  will 
be  conducted  prlaarily  on  digital  nets.  Coaaand  and  Control  and  admlnlstra- 
tive/loglstleal  communications  will  be  conducted  primarily  on  the  voice  net. 

The  howitzer's  voice  radio  and  wire  backup  capabilities  will  be  evaluated. 
Operations  will  be  conducted  in  varied  terrain  conditions,  during  day  and 
night  operations.  In  various  NBC  mission-oriented  protected  postures,  up  to 
and  including  MOPP  IV.  The  test  will  be  conducted  in  a  hostile  EM/EW  environ¬ 
ment  including  active  ECM,  representative  of  the  anticipated  threat  and  coun¬ 
termeasures.  The  howitzer  will  operate  in  an  automated  mode,  using  the  on¬ 
board  processor  for  ballistic  computations  (FFE  missions),  mission  storage, 
armament  position/direction,  safety,  firing,  (commands  and  data)  fuze  setting 
(if  included  as  part  of  HIP  modifications),  message  traffic,  and  on-board 
diagnostics/prognostics.  The  evaluation  of  the  utility  of  the  on-board 
processor  for  Improving  command  and  control  of  the  HIP  howitzer  is  investiga¬ 
tive  in  nature.  The  unit's  capability  for  operating  in  a  degraded  C^  mode 
will  be  evaluated  and  is  investigative  in  nature. 

(2)  Criteria. 

(a)  The  HIP  howitzer  must  receive  and  transmit  the 
density  of  communlcatlons/message  traffic,  under  conditions  and  over  distances 
required  by  the  approved  OT  tactical  scenario. 

(b)  The  HIP  howitzer's  external  communications  system 

must  communicate  via  voice  or  digital  radio,  with  the  nodes  specified  in  the  040 
Plan  (including  ATHS,  AFATDS,  BCS,  FIST  DMD,  FO  DMD,  Q36,  Q37,  RPV 

(ground  station))  under  conditions,  and  over  distances  required  by  the  ap¬ 
proved  OT  tactical  scenario. 

(c)  When  the  howitzer's  voice  and  digital  communications 
systems  are  Inoperable  the  HIP  howitzer  must  communicate  by  wire  with  other 
howitzers  and  the  platoon  FDC  over  distances  of  at  least  100  meters. 

(d)  The  howitzer's  Internal  communications  system  must 
transmit  and  receive  at  each  on  board  station. 

(3)  Nationals.  An  effective  external  and  internal 
communications  system  will  enable  the  HIP  howitzer  to  provide  responsive  and 
effective  fire  support  while  executing  semi-autonomous  (dispersed  positioning) 
operations.  A  backup  capability  is  required  for  continuous  operations  when 
voice  and  digital  communications  are  degraded  to  unacceptable  levels. 

(4)  Source.  040  Plan,  Chapter  4;  LOA,  Para.  3c(4),  (6), 

3e(i);  LOA/ Annex  A,  Para.  4f;  ARTEP  6-100.  ARDC  Training  Manual  TS-85-1. 

d.  Issue  4.  Is  the  HIP  howitzer's  moblllty/transportablllty 
adequate?  ~  ^ 

(1)  Scope.  A  combat-loaded  HIP  howitzer's  capability  for 
meeting  the  mobility  requirements  specified  in  the  0MS/MP  will  be  evaluated. 
Frequent  emplacements,  displacements  and  road  marches  are  required  to  provide 
continuous  fire  support  for  the  maneuver  forces.  The  operational  scenario 


E2-B-9 


will  b«  based  on  twenty-four  hour  OMS/MP  wartime  weighted-average  periods.  The 
utility  of  the  howitzer's  day/night  vision  devices  will  be  evaluated  and 
recorded.  Day  and  night  operations  will  be  conducted  in  both  opened  and  closed 
vehicle  configurations,  while  traveling  cross-country  and  on  priaary  and 
secondary  roads,  under  varied  terrain  conditions.  The  assessaent  of  howitzer 
aoblllty  will  Include  an  analysis  using  the  TACOM  NATO  Reference  Mobility  Model. 
An  anal)«.lcal  assessaent  of  the  ability  of  the  HIP  howitzer  to  aeet  applicable 
air,  rail,  bridge,  and  tunnel  restrictions  is  required.  The  HIP  howitzer's 
capability  for  being  tactically  loaded,  off-loaded  and  prepared  for  action  by 
representative  soldiers  using  TOE  equlpaent  and  tie-down  devices  on  road,  rail, 
sea,  and  air  carriers  will  be  evaluated. 

(2)  Criteria. 


(a)  Coabat-loaded  HIP  howitzers  in  a  fully  operational 
status  aust  aeet  the  aoblllty  requlreaents  specified  for  the  OMS/MP  twenty-four 
hour  wartlae-welghted  average;  10  aoves  totaling  22  ka. 

(b)  The  HIP  howitzer  aust  provide  the  vehicle  driver  the 
day/night  vision  capability  to  conduct  tactical  operations  In  a  closed  vehicle 
configuration. 


(c)  Coabat-loaded  HIP  howitzers  aust  achieve  the 
following  speeds  while  operating  in  a  tactical  environment. 


Primary  Roads: 
Priaary  Roads: 
Secondary  Roads: 
Cross  Country: 


55  KPH/34  MPH  (Maxiaum) 

35  KPH/22  MPH  (Average) 

25  KPH/15  MPH  (Average) 

20  KPH/12  MPH  (V-80  dry  conditions 
using  TACOM' s  NATO  Reference  Model) 


(d)  The  HIP  howitzer  must  be  as  transportable  as  the 
M109E4,  155am  self-propelled  howitzer  by  road,  rail,  sea  and  air  (C5A)  (AR70-44 
applies).  The  HIP  howitzer  aust  aeet  European  rail,  bridge,  and  tunnel 
restrictions.  MIL-STD-209,  810  and  1366  (Envelopes  A  and  B)  will  apply. 

(e)  The  howitzer  crew,  using  the  required  tools  and 
equlpaent  aust  deaonstrate  the  capability  to  load,  secure,  off-load,  and  prepare 
the  HIP  howitzer  for  action  in  tlaes  equivalent  to  those  required  for  the 
M109A2/A3. 


(f)  Lifting  and  tie  down  procedures  for  the  HIP 
howitzer  will  aeet  the  specif icatons  of  MIL-STD-209. 

(g)  Coabat-loaded  HIP  howitzers  aust  achieve  a  cruising 
range  of  at  least  300  ka  when  traveling  on  priaary  roads  at  35  kph/22  aph. 

(h)  Coabat-loaded  HIP  howitzers  aust  achieve  a  fording 
depth  of  at  least  42  Inches  (1.07  aeters)  . 
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(3)  Rationale.  To  enable  HIP  unite  to  provide  cloae  and 
continuous  fire  support,  the  HIP  howitzer's  speeds  must  be  equivalent  to  the 
M109A2/A3.  Frequent  emplacements,  displacements,  end  road  marches,  as  specified 
in  the  OMS/MP,  ere  required.  The  HIP  howitzer  must  be  as  transportable  by  road, 
rail,  sea,  and  air  (C5A)  as  the  unit  that  it  habitually  supports.  Howitzer 
speeds  are  based  on  a  TACOM  cross-country  mobility  study  using  the  HATO 
Reference  Model* 


(4)  Source.  LOA,  Para.  3e(l),  (5),  3e(l);  LOA/ Annex  A,  Para. 
4f;  TACOM  Mobility  Analysis. 

2.  Survlvablllty/Vulnerabllity. 

a.  *Isaue  5.  Are  the  HIP  howitzer's,  crew's,  and  unit's  surviv¬ 
ability  and  vulnerability  characteristics  adequate? 

(1)  Scope.  Operations  will  be  conducted  in  simulated  NBC 
contaminated  and  realistic  electronic  warfare  (including  jamming)  environ¬ 
ments,  and  when  HIP  units  are  faced  with  the  threat  of  ground  and  air  attacks. 
Howitzer  crews  and  equipment  will  be  stressed  by  performing  day  and  night 
operations,  1AW  the  OMS/MP,  while  the  crew  la  wearing  ventilated  facepiece  and 
microcooling  equipment  In  various  MOPP  conditions,  up  to  and  including  MOPP 
IV.  Personnel  and  equipment  decontamination  procedures  will  be  evaluated. 
Performance  degradation  while  operating  in  NBC,  NVE,  and  EV  environments  will 
be  assessed.  This  issue  requires  an  evaluation  of  the  capabilities  of  the 
on-board  electronics  and  electrical  devices  for  operating  while  under  the 
adverse  conditions  caused  by  electromagnetic  effects  (including  electromag¬ 
netic  interference  and  compatibility,  RF  susceptibility,  lightning  suscepti¬ 
bility,  electrostatic  discharge,  TEMPEST,  high  altitude,  electromagnetic  pulse 
and  nuclear  weapons  effects)  and  electronic  countermeasures/electronic 
counter-countermeasures.  In  addition,  the  howitzer's  and  unit's  capability 
for  firing  direct  fire  when  faced  with  a  ground  attack,  and  making  survivabil¬ 
ity  displacements  when  subjected  to  enemy  counterfire  will  be  evaluated. 

Testing  on  a  HIP  howitzer  ballistic  hull  and  turret  will  be  conducted  to 
evaluate  the  reduction  in  vulnerability  provided  to  the  crew  and  critical 
howitzer  components  by  application  of  the  HIP  vulnerability  improvement  kit. 

(2)  Criteria. 

(a)  The  product  improved  items  integrated  into  the  HIP 
howitzer  will  meet  the  nuclear  survlvabllilty  standards  derived  from  QSTAG  244. 

(b)  The  HIP  howitzer  crew  must  operate  the  howitzer  for  a 
period  of  at  least  12  hours  while  In  MOPP  IV  equipment,  with  an  average 
individual  and  collective  mission-essential  task  performance  degradation  of  not 
more  than  S  percent  as  a  measure  of  time  (when  compared  with  the  initial 
performance  level  on  the  first  iteration  of  the  task.  Mission-essential  tasks 
include: 


_1_.  Prepare  howitzer  for  conduct  of  fire  missions. 
2.  Execute  fire  commends. 
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3^  Recover  end  prepere  for  movement. 

Score  end  trenaport  ammunition. 

(c)  There  auac  be  no  more  than  a  negligible  risk  (5 
percent)  of  heat  etress  casualties  for  a  HIP  howitzer  crew  in  MOPP  IV  equlpaent 
performing  mission-essential  tasks  for  a  period  of  at  least  12  hours. 

(d)  A  HIP  howitzer  aust  be  decontaainated  by  its  crew 
using  standard  TOE  field  decontaminants,  equlpaent  and  procedures  in  not  more 
than  one  hour.  Standard  decontamination  procedures  will  not  adversely  affect 
howitzer  systea  functions. 

(e)  The  HIP  howitzer's  on-board  electronics  and 
electrical  devices  aust  be  operable  without  degradation  when  subjected  to 
adverse  electroaagnetic  effects  la  accordance  with  MIL-STD-461,  -462,  -1757,  and 
-331  and  HICOM-TR-RT-81-5. 

(f)  The  HIP  howitzer  aust  be  certified  for  TEMPEST  per 
NACSIM5100A  and  NACSEM  5112,  Appendix  A. 

(g)  The  HIP  howitzer  and  crew  aust  initiate  emergency 
and  survivability  displacements  in  less  than  one  alnute  after  being  given  the 
order  to  displace. 


(h)  The  HIP  howitzer  unit  must  fire  Its  primary  and 
secondary  araaaent  In  direct  fire  IAV  the  procedures  In  FM  6-50,  and  IAN  the 
tasks,  conditions  and  standards  of  ARTEP  6-100. 

(1)  Ballistic  protection  provided  to  the  HIP  howitzer 
will  reduce  the  vulnerability  (type  TBD)  to  the  crew  and  selected  critical 
components  when  compared  to  protection  afforded  to  the  M109A3E1. 

(3)  Rationale.  HIP  howitzer  units  face  threats  from  enemy 
artillery,  NBC  munitions,  armor,  mechanized  Infantry,  aircraft,  armed  helicop¬ 
ters,  electronic  warfare,  and  dismounted  special  forces.  The  criteria  for  NBC 
survivability  are  specified  In  DCSOPS  letter,  subject:  DA  Approved  Quantita¬ 
tive  NBC  Contamination  Survivability  Criteria,  7  February  1985.  Procedures 
for  battery  defense  versus  ground  and  air  targets  are  explained  in  detail  in 
FM  6-50  and  ARTEP  6-100.  Emergency  displacement  times  are  specified  In  ARTEP 
6-100.  Mission-essential  howitzer  section  performance  tasks  are  those 
mandatory  tasks  specified  In  ARTEP  6-100. 

(4)  Source.  L0A,  Psra.  3s(l),  (2),  (3),  (4),  (5),  (6). 

QSTAC  244  standards  are  specified  In  USANCA  letter,  20  Jsn  84,  Subject: 

Nuclear  Survivability  Criteria  for  the  Howitzer  Improvement  Program  (HIP),  AR 
70-7 1 . 
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•* 3.  Reliability.  Availability,  and  Maintainability. 

a.  *Issue  6.  la  the  operational  availability,  reliability, 
and  maintainability  of  the  HI?  howitzer  adequate  to  enaure  that  the  system 
will  be  operationally  effective  and  loglatlcally  supportable  when  fielded? 

(1)  Scope.  The  operational  availability,  reliability,  and 
Maintainability  of  the  howitzer  will  be  deaonatrated  while  operating  1AV  the 
OMS/HP.  Teat  data  will  provide  an  estimate  of  HIP  howitzer  durability. 
Operationa  will  be  conducted  LAW  the  condltiona  aped  fled  for  twenty-four  hour, 
OMS/MP  weighted-average  periods  during  day  and  night  and  In  varied  terrain, 
bquipaent  failures  will  be  recorded  and  reported  1AW  the  procedures  specified  In 
the  RAM  Annex  of  the  HIP  LOA.  The  howitzer  will  be  operated,  Maintained,  and 
repaired  by  representative  soldiers  In  a  tactical  environment.  Operational 
availability  is  the  principal  aeasure  of  user  readiness  requirements. 

(2)  Criteria. 


(a)  The  HIP  howitzer  aust  achieve  a  wartime  operational 
availability  (Ao)  of  at  least  0.60  when  equipped  with  a  modified  M185/M178 
armament  systea. 

(b)  The  HI?  howitzer  aust  achieve  a  Mean  Time  Between 
Operational  Mission  Failures  (MTBOMP)  of  at  least  90  hours  when  equipped  with 
the  modified  Ml 85 /Ml 78  araament  system. 

(c)  The  RIP  howitzer  aust  achieve  a  mean  time  between 
essential  aalntenance  actions  (KTBEMA)  of  at  least  20  hours. 

(d)  The  following  alnlaum  acceptable  values  for 
maintainability  will  be  attained  when  equipped  with  either  the  modified 
M185/M178  armament  systea  or  the  advanced  armament  aystem  (new  39  caliber 
cannon  and  new  modular  gun  aount). 


Parameter 

MAY 

MR/UNIT 

0.14 

MR/I(DS)-0N 

0.099 

MR/I(OS)-OFF 

0.028 

MR/l-CS 

0.090 

(3)  Rationale.  The  frequency  of  mission  stopping  failures  am 
the  capability  of  the  support  system  to  repair  and  return  equipment  to  action 
are  the  most  significant  factors  contributing  to  operational  RAM.  Assumptions 
made  to  support  user  analysis  leading  to  establishment  of  the  tentative  RAM 
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requirement*  above  Include:  operation  In  accordance  with  the  HIP  OMS/MP  ae 
preaented  In  Annex  A  of  the  HIP  LOA;  the  HIP  failure  definition/ acorlng 
criteria;  trilevel  maintenance  support;  firing  a  mix  of  propelling  charges 
consisting  of  4.1Z  M203,  7.0Z  M119,  37.1Z  M4A1  and  S1.8Z  M3A1  (based  on 
results  of  SCORES  Europe  I,  Sequence  1IA  analysis);  and  manpower  constrained 
by  Army  of  Excellence  force  levels* 

(4)  Source.  LOA,  Para.  3b(l)  and  Annex  E. 

4,  Organization  and  Operation. 

a.  Issue  7.  Does  the  HIP  battalion**  organizational  TOE 
provide  the  personnel  and  equipment  necessary  for  the  unit  to  perform  seal- 
autonomous  operations? 

(1)  Scope.  Tactical  operations  will  be  conducted  In  simu¬ 
lated  wartime  environment  using  the  SCORES,  Europe  V  scenario.  The  unit  will 
be  stressed  during  day  and  night  operations,  IAW  the  OMS/MP,  In  varied  terrain 
conditions,  while  the  crew  Is  In  various  NBC  mission-oriented  protective 
postures  up  to  and  including  MOPP  IV.  Operations  identified  in  the  040  Plan 
will  be  conducted  and  the  adequacy  of  the  TOE  organization  for  accomplishing 
the  unit's  performance  of  aemiautonomous  operations  while  moving,  shooting, 
and  communicating  in  support  of  the  maneuver  commander  will  be  assessed. 
Semlautonomous  operations  refers  to  the  dispersed  positioning  of  Individual 
howitzers  within  a  one  kilometer  diameter  circle  during  periods  of  Incense 
counterfire  threats. 

(2)  Criterion.  This  Issue  is  investigative  in  nature. 

(3)  Rationale.  The  HIP  TOE  contains  devlstions  from  the 
current  135mm  SP  howitzer  battalion  TOE.  An  assessment  of  the  HIP  organiza¬ 
tion's  adequacy  is  necessary  to  ensure  that  the  TOE  will  support  a  unit's 
ability  to  conduct  semlautonomous  operations.  k 

(4)  Source.  Operational  and  Organizational  Plan,  Chapter  3. 

b.  Masue  8.  Are  the  planned  doctrine,  tactics,  and  tech¬ 
niques  for  HIP  units  adequate? 

(1)  Scope.  Tactical  operations  will  be  conducted  in  simu¬ 
lated  wartime  environment  using  the  SCORES,  Europe  V  scenario.  The  HIP  unit 
will  be  stressed  during  day  and  night  operations,  IAW  the  OMS/MP,  in  varied 
terrain  conditions,  and  while  the  crew  la  in  various  NBC  mission  oriented 
protective  postures  up  to  and  including  MOPP  IV.  The  adequacy  of  the  doc¬ 
trine,  tactics,  and  techniques  for  HIP  units  performing  semi-autonomous  opera¬ 
tions  while  moving,  shooting,  and  communicating  in  support  of  the  maneuver 
force  will  be  assessed.  Semleutonoaous  operation  refers  to  the  dispersed 
positioning  of  individual  howitzers  within  a  one  kilometer  diameter  circle 
during  periods  of  intense  counterfire  threats.  Testing  of  the  doctrine, 
tactics,  and  techniques  based  upon  the  HIP  040  concept  and  tactical  SOP.  The 
HIP  howitzer  will  demonstrate  the  capability  to  complete  to  standards  100 
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percent  of  the  etteapted  applicable  aandatorytasks  contained  in  ARTEP  6-100. 
Non-mandatory  tasks  will  be  selected  by  the  test  director  based  on  those  tasks 
that  will  occur  during  the  exercise  scenario.  The  scoring  systea  will  provide 
a  percentage  GO/NO  GO  score  In  each  of  the  seven  bettalion  alsslon/ tasks. 
Battalion  and  battery  fire  alsslons  will  be  scored  for  both  tlae  and  accuracy 
IAW  the  derived  HIP  ARTEP. 

(2)  Criteria. 

(a)  The  evaluated  battalion/battery  aust  successfully 
accoapllsh,  as  a  minimum,  80  percent  of  the  specified  battalion/battery  live- 
fire  alsslons  and  100  percent  of  the  specified  dry-fire  alsslons  to  HIP  ARTEP 
standards . 


(b)  The  HIP  howitzer  battalion  aust  achieve  a  alniaua 
of  80  percent  overall  “GOs"  under  the  HIP  ARTEP  Standards,  for  each  of  the 
seven  battalion  ARTEP  tasks:  (1)  coordinate  fire  support;  (2)  acquire  tar¬ 
gets;  (3)  deliver  field  artillery  fires;  (4)  communicate;  (5)  movement;  (6) 
maintain  and  resupply;  and  (7)  perform  survivability  operations. 

(c)  The  HIP  unit  oust  successfully  accomplish  100  percent 
of  the  nuclear  tasks  required  In  ARTEP  6-100. 

(3)  Rationale.  The  HIP  060  Plan  contains  significant  devia¬ 
tions  froa  current  155mm  SP  howitzer  unit  opera' 4 'ns.  An  assessaent  of  HIP 
doctrine,  tactics,  and  techniques  Is  necessary  >  nsure  that  units  are  capa¬ 
ble  of  conducting  semlautonoaous  operations  while  providing  continuous, 
responsive,  and  effective  fire  support  for  maneuver  forces.  Following  the 
scoring  systea  of  ARTEP  6-100  will  allow  the  evaluation  of  a  HIP  unit's 
strengths  and  weaknesses.  It  also  provides  a  realistic  measure  of  the  effec¬ 
tiveness  of  the  HIP  provided  by  the  training  support  package. 

(4)  Source.  HIP  060;  ARTEP  6-100;  HIP  Tactical  SOP. 

5.  Interoperability. 

a •  *Isauc  9.  Does  the  HIP  howitzer  unit  adequately  inter¬ 
face  and  Interoperate  with  the  fire  support  system? 

(1)  Scope.  The  capabilities  of  the  HIP  howitzer  and  its 
unit's  coaaunlcations  equipment  will  be  demonstrated  during  tactical  operations 
conducted  LAW  the  OMS/MP  twenty-four  hour,  wartlae  weighted-average  to  evaluate 


the  adequacy  of  their  Interoperability  with  the  fire  eupport  systea.  The  HIP 
howitzer  unit  will  directly  receive  fire  alaaiona  requesting  approved  lSSaa 
ehell/fuze/propellant  coablnationa  froa  field  artillery  target  acquisition 
sources  (Including  FIREFINDER,  the  RPV  ayatea,  FIST,  observers,  laser  teaas,  and 
brigade  and  battalion  fire  support  sections).  All  fielded  US  155aa  projectiles, 
fuzes,  prlaer  ignition  systeas  (except  the  MK2A4  prlaer),  and  propelling  charges 
will  be  fired  during  the  evaluation  of  the  HIP  howitzer's  aodlfled  M185/M178 
araaaent  systea.  An  analytical  assessaent  of  the  HIP  howitzer's 
Interoperability  with  developaental  155am  aunitlons  will  be  perforaed. 
Aaaunitlon  transfer  operations  using  field  artillery  aaaunltion  support  vehicles 
will  be  conducted.  The  RIP's  standardization  program  and  its  commonality  with 
the  Aray  support  system  will  be  evaluated  during  the  logistics  support 
assessaent  review  process. 

(2)  Criteria. 

(a)  The  HIP  howitzer  aust  interface  and  interoperate, 
through  its  on-board  communications  systea  with  the  field  artillery  fire  support 
hardware  and  software  (e.g.,  BCS,  AFATDS)  at  battalion  operations  centers, 

fire  support  eleaents  (Include  brigade,  battalion  and  FIST),  platoon  fire 
direction  centers  and  target  acquisition  sources;  as  specified  in  the  HIP  User 
Interface  Requirements  (UIR)  document  and  HIP  Operational  and  Organizational 
Plan. 

(b)  The  HIP  modified  M185/M178  armament  system  must 
fire  all  fielded  and  developmental  US  I55aa  projectiles,  fuzes,  prlaer  Ignition 
systeas  (except  the  MK2A4  primer)  and  propelling  charges  (except  those 
specifically  developed  for  the  advanced  armament  aystem  and  extended  range 
cannon) . 


(c)  The  HIP  howitzer  must  interoperate  with  field 
artillery  ammunition  support  vehicles,  l.e.,  receive  projectiles  froa  a  FAASV  at 
the  rate  of  at  least  four  complete  rounds  per  minute,  and  perform  ammunition 
uploads  of  34  complete  conventional  geometry  rounds  and  2  Copperhead  rounds  in  a 
median  time  of  less  than  20  minutes  in  an  uncontaalnated  environment. 

O)  Rationale.  HIP  howitzer  units  must  have  digital  data  and 
voice  communications  Interfaces  with  the  fire  support  systea  to  support  the 
maneuver  commander.  The  capability  for  ualng  all  fielded  and  developmental  US 
155mm  munitions  is  cost  effective  and  fully  uses  the  existing  and  planned  US 
inventory,  reduces  the  logistics  and  training  burdens  associated  with  the 
restricted  use  of  certain  munitions  combinations,  and  eliminates  the  need  to 
develop  unique  munitions.  Commonality  between  vehicles  and  commonality  with  the 
Aray  aupport  systea  reduces  the  logistics  burden  and  training  required  to 
maintain  and  support  the  HIP  howitzer. 

(4)  Source.  LOA,  Para.  3b(3),  3c(6),  (7),  (8),  and  3d(4); 

User  Interfsce  Requirements  (UIR). 
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6 


MANPRINT 


a.  «lssue  10.  Is  the  HIP  howitzer  ufe  to  operate,  maintain. 

and  repair? 

(1)  Scope*  This  issue  addresses  the  HIP  howitzer  end  its 
support  aqulpaent's  capability  for  safe  crew  operation,  aalntenance,  and 
repair  in  an  operational  environment.  Hazards  identified  will  be  categorized 
IAW  M1L-ST-882.  Measurement  of  the  crew's  air  supply  will  be  taken  with  and 
without  collective  NBC  protection  equipment,  and  in  open  and  closed  howitzer  - 
configurations* 

(2)  Criteria. 

(a)  The  syaten  will  be  evaluated  to  ensure  that  there 
are  no  hazards  with  a  hazard  severity/hazard  probability  rating  of  IA,  B,  C, 

D;  1IA,  B,  C,  AND  IIIA  (Deficiencies),  and,  if  economically  feasible,  from 
cost-benefit  analysis  1ID,  111B,  C  (Shortcomings).  (See  attached  Hazard 
Probability  versus  Severity  Chart,  Fig.  8-1). 

(b)  Electromagnetic  radiation  hazards  will  be 
controlled  1AV  TB  MED  523. 

(c)  The  HIP  howitzer  will  not  expose  crew  or 
aalntenance  personnel  to  concentrations  of  toxic  substances  or  gases  in  excess 
of  the  limits  specified  in  the  Handbook  of  American  Conference  of  Government 
Industrial  Hygienists.  This  includes  exposure  to  HALON  1301,  the  substance 
contained  in  the  fixed  fire  suppression  system. 

(d)  The  air  supply  to  the  crew  shall  meet  toxicity 
criteria  with  respect  to  combustion  products  from  weapon  firing  and  internal 
combustion  engine,  as  outlined  in  M1L-STD-1472  and  M1L-HDBK-759. 

(e)  The  electronics  and  electrical  environment  of  the 
systeta  will  meet  the  parameters  of  MIL-STI^454. 

(f)  The  noise  profile  of  the  RIP  howitzer  during  all 
modes  of  operations  will  meet  MIL-STD-1474  requirements. 

(3)  Rationale.  To  Identify  safety-related  deficiencies,  an 
assessment  and  analysis  of  Inherent  and  operational  safety  problems,  a6  well 
as  freedom  from  health  hazard  risks,  must  be  conducted. 

(4)  Source.  NIL-STDS  454,  882,  1472  and  1474;  TB  MED 
523;  AR  385-16;  LOA,  Para.  3(e)  2;  and  M1L-HDBK-759. 

b.  Issue  11.  Is  the  HIP  howitzer's  human  factors  engineer¬ 
ing  (HFE)  design  acceptable? 
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HAZARD  PROBABILITY 


Figure  B-J. .Hazard  Probability  vs.  Hazard  Severity 


(1)  Scope.  This  Issue  assesses  the  HIP  howitzer's 
capability  for  aeeting  the  aan-machine  interface  criteria  outlined  in  MIL-STD- 
1472. 

(2)  Criteria. 

(a)  The  HIP  howitzer  will  Beet  the  HFE  requirements  of 

MIL-STD-1472. 

(b)  The  HIP  howitzer  will  be  capable  of  being  operated, 
maintained  and  repaired  at  the  unit  level  by  90Z  of  MOS  13B  soldiers. 

(c)  The  HIP  howitzer  will  be  capable  of  being 
maintained  and  repaired  at  the  intermediate  level  by  90 Z  of  the  soldiers 
normally  assigned  to  perform  those  duties.  . 

(d)  The  HIP  howitzer  must  provide  working  space  for 
operation,  maintenance  and  repair  of  the  system  by  90Z  of  the  soldiers 
normally  assigned  to  perform  those  duties. 

(e)  The  HIP  howitzer  must  provide  space  for  Ingress  and 
egress  (normal  and  emergency)  by  a  95Z  of  HOS  13B  soldier  dressed  In  arctic 
and/or  NBC  protective  clothing. 

(f)  The  HIP  howitzer  aust  provide  seating  that  will 
accommodate  95Z  of  MOS  13B  soldiers  and  permit  performance  of  crew  tasks  in 
all  modes  of  operation  without  degradation. 

(g)  The  HIP  howitzer  shall  be  designed  so  that  controls 
and  displays  are  visible,  accessible  and  operable  by  95Z  of  MOS  13B  soldiers 
when  dressed  In  arctic  and/or  NBC  protective  clothing. 

(h)  The  HIP  howitzer  must  provide  lighting  for  all 
tasks  during  all  Bodes  of  operation  LAW  MIL-STD-1472.  All  controls,  displays 
and  Indicators  aust  be  visible  during  all  tactical  operations. 

(1)  The  HIP  howitzer  aust  provide  ventilation  and  heating 
IAW  MIL-STD-1472  for  the  full  range  of  environmental  conditions. 

(j)  The  HIP  howitzer  aust  provide  space  for  storage  of 
water  and  onboard  vehicle  equipment  (OVE)  that  permits  an  access  by  93Z 

of  MOS  13B  soldiers  and  does  not  require  reaovsl  of  other  equipment. 

(k)  The  HIP  howitzer  must  provide  aanual  backup 
capability  for  emplacement,  lay,  loading,  and  firing  functions  with 
performance  equal  to  or  better  than  the  M109A2/A3  when  In  a  similar  config¬ 
uration  (e.g.,  power  reaming  or  hand  ramming). 


E2-B-19 


(1)  The  HIP  howitzer  auet  provide  speech  intelligible 
intra-vehicle  coaaunicatlone  during  ell  aodes  of  operation  Including  firing 
end/or  while  the  vehicle  engine  is  operating. 

(3)  Rationale.  An  assessment  and  analysis  of  the  saa- 
aachlne  Interface  aust  be  conducted  to  identify  and  correct  hunan  factors 
engineering  deficiencies  of  the  HIP  howitzer. 

(A)  Source.  AR  602-1;  MIL-STD  1472;  MIL-HDBK-759; 

Soldier  Support  Center. 

c.  Issue  12.  Can  the  HIP  howitzer  unit  operate  in  the 
range  of  natural  environments  expected  for  worldwide  deployment? 

(1)  Scope.  The  capability  of  the  HIP  howitzer  for  operating 
In  normal,  desert,  arctic,  and  tropic  envlronaents  will  be  evaluated.  The 
howitzer's  human  factors,  safety,  operational  and  crew  performance 
characteristics  will  be  stressed  during  operations  in  each  environment. 
Operations  stressing  the  system's  technical  characteristics  and  the  man- 
machine  Interface  will  be  conducted.  All  subsystems  will  be  individually 
evaluated  in  addition  to  a  total  system  being  evaluated. 

(2)  Criteria. 

(a)  The  HIP  howitzer  will  be  operable  in  hot,  cold 
(with  winterization  kit),  and  basic  climatic  conditions  IAW  AR  70-38. 

(b)  Ninety  percent  of  MOS  13B  soldier's  will  operate, 
maintain,  reload,  and  repair  the  HIP  howitzer  while  wearing  cold  weather  and 
MOPP  IV  equipment. 

(3)  Rationale.  The  HIP  howitzer  must  be  operable  in  all 
expected  climates. 

(4)  Source.  LOA,  Para.  3e(3);  AR  70-38;  Soldier  Support 

Center. 


d.  *Isaue  15.  Can  the  representative  soldier  and  tht  HIP 
howitzer  unit,  after  being  trained  IAW  the  test  training  support  package  (TTSP), 
adequately  operate,  maintain,  and  employ  the  HlP-howltzer? 

(1)  Scope.  This  issue  assesses  the  ability  of  soldiers  and 
units  to  effectively  operate,  maintain,  and  employ  the  howitzer  in  an 
operational  environment.  The  adequacy  and  efficiency  of  the  training  and 
training  support  materials,  envisioned  for  supporting  the  howitzer  when 
fielded,  will  be  evaluated.  Training  will  be  conducted  on  those  individual 
and  collective  training  tasks  Identified  during  the  Job/task  analysis  for 
operating  and  maintaining  the  nIP  howitzer  IAW  approved  doctrine  and  tactics. 

A  pretest  will  be  administered  to  all  test  players  to  ensure  that  they  possess 
the  skills  and  knowledge  associated  with  their  designated  HOSs.  Prior  to  test 
player  training,  the  soldier  must  be  capable  of  performing  MOS  tasks,  as 
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specified  in  the  appropriate  soldier's  manual.  Upon  completion  of  test 
players  training,  test  players  will  be  certified  as  being  trained,  IAU  the 
TTSP,  to  perform  individual  and  collective  tasks  to  prescribed  standards.  The 
TTSP  will  contain  the  draft  institutional  P01 ,  unit  training  materials  (field 
manuals/ circulars)  to  train  the  0&0  Plan,  and  all  institutional  materials, 
training  aids,  and  simulations  envisioned  for  fielding  with  the  HIP  howitzer. 
All  performance  problems  experienced  during  the  test  along  with  comments  from 
test  players  will  be  analysed  to  determine  the  effectiveness  of  the  training 
program.  Problems  attributed  to  an  Inadequate  training  program  will  be  used 
as  a  basis  for  revising  the  individual  training  plan,  individual  and  collec¬ 
tive  training  plan,  institutional  POI,  unit  OJT  program,  and  modifications  of 
the  training  devices.  The  draft  test  ARTEP  will  be  evaluated  based  on  the 
performance  of  the  B1P  hovltter  section,  platoon,  battery,  and  battalion 
(investigative  in  nature). 

(2)  Criteria. 


(a)  The  representative  soldier  mu6t  achieve  the 
training  standards  specified  in  the  TTSP  for  all  HXP-related  tasks. 

(b)  The  training  and  test  support  materials  must 
prepare  the  HIP  hovltter  section,  platoon,  battery,  and  battalion  for 
performing  HIP-related  tasks  LAW  the  TTSP  Draft  ARTEP  standards. 

(c)  All  training  literature  must  be  vrltten  at  the  7th 
grade  reading  level  and  contain  accurate  illustrations  and  procedures  for  all 
training  tasks. 


(3)  Rationale.  The  training  program  must  answer  the 
questions  of  what  tasks  must  be  performed  in  what  manner,  under  what 
conditions,  in  response  to  vhat  cues,  and  to  what  standard  for  the  various 
HOSs  in  HIP  units.  The  new  equipment  training  (NET)  team,  using  the  TTSP, 
should  prepare  the  test  players  and  units  to  safely  and  efficiently  operate 
and  maintain  the  hovltter  IAV  approved  doctrine  and  training.  The  planned 
institutional  and  OJT  training  programs  must  be  capable  of  implementation 
within  TRADOC  schools  and  FORSCOM  units. 

(4)  Source.  USAFAS. 

e .  Issue  16.  Do  HIP  training  devices  and  simulators  ade¬ 
quately  train  the  soldier  and  unit  to  perform  individual  and  collective  tasks 
to  the  designated  level  of  proficiency  and  is  the  training  devlces/slmulstors 
RAM  adequate  to  ensure  that  they  will  be  effective  and  loglstlcally  support¬ 
able  when  fielded? 

(1)  Scope.  This  issue  assesses  the  adequacy  of  training 
devices  and  simulators  developed  for  HIP  howitzer  training.  An  assessment  of 
training  transfer  from  the  device  to  operational  equipment  will  be  conducted. 
The  training  time  and  the  number  of  iterations  required  to  achieve  proficiency 
in  the  required  tasks  will  be  evaluated.  RAM  data  on  training  devices  will  be 
collected.  All  maintenance  actions  required  of  the  test  players,  Instructors 
and  contractors,  for  repairing  training  devices  will  be  recorded.  Parts 
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required  to  repair  and  return  the  HIP  training  devices  to  an  operational 
condition  will  be  reported,  as  vl 11  all  operational  and  maintenance  downtimes. 

(2)  Criteria. 

(a)  Training  devices/siaulators  will  train  soldiers  and 
units  to  perform  designated  Individual  and  collective  tasks  to  standards 
prescribed  in  the  TTSP. 

(b)  The  training  device  system  must  schleve  a  mean  time 
between  operational  mission  failures  (MTBOMF)  of  at  least  80  hours  when 
operated  in  an  institutional  environment. 

(3)  Rationale.  The  capability  of  training  devices  for 
training  individuals  and  HIP  units  to  the  TTSP  standards  requires  testing  and 
evaluation.  Training  devices  must  demonstrate  the  ability  to  correctly 
transfer  skills  from  the  training  device  to  the  actual  equipment. 

(4)  Source.  USAFAS. 

7.  Logistics. 

a.  *Issue  13.  Is  the  HIP  unit,  when  supported  IAW  the 
spproved  logistics  concept,  using  the  system  support  package  (SSP) ,  support¬ 
able  through  intermediate  level  maintenance? 

(1)  Scope.  The  HIP  unit  will  be  logistlcally  supported  IAW 
the  logistics  concept  described  In  the  doctrine  and  organizational  support 
package.  The  system  will  adhere  to  the  trllevel  maintenance  structure  and 
forward  support  doctrine.  Maintenance  will  be  performed  as  described  by  the 
maintenance  allocation  charts  (MAC)  snd  LAW  the  instructions  contained  in  the 
equipment  publications  (technical  manuals)  using  the  tools,  TMDE,  repair 
parts,  and  other  support  items  contained  In  the  SSP.  Maintenance  tasks  con¬ 
tained  in  the  MAC*  will  be  verified  by  using  representative  soldiers  to  ensure 
that  designated  unit  tasks.  Intermediate  DS  tasks,  and  Intermediate  GS  tasks 
can  be  accomplished  In  sn  operational  environment.  If  necessary,  failures 
will  be  artificially  Introduced  to  ensure  the  adequate  evaluation  of  main¬ 
tainability  and  supportablllty  Issues.  The  SSP  Items,  as  Identified  in  the 
DT/OT  System  Support  Package  Component  Listings  (SSPCLs),  will  be  accounted 
for  and  available  at  the  DT/OT  test  sites  prior  to  test.  Required  SSP  items 
include:  operator's  manusls;  unit  and  Intermediate  maintenance  technical 
manuals;  unit  and  Intermediate  maintenance  repair  parts  snd  special  tools 
lists  technical  manuals;  lubrication  orders;  repair  parts;  special  tools; 
commoo  tools;  test,  measurement  and  diagnostic  equipment  (including  BIT  and 
BITE);  material  handling  and  transporting  equipment  (e.g.,  M992  FAASV,  MS48 
ARV);  and  other  support  equipment  (e  g.,  M578  LMV,  generators,  trucks, 
trailers). 
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•The  MAC  le  •  table  of  work-time  figure  representing  the 
average  tlaea  required  to  restore  an  item  to  a  serviceable  condition  under 
typical  field-operating  conditions.  This  tine  includes  preparation  time, 
troubleshooting  tlae,  tlae  required  to  perfora  specific  maintenance  tasks  and 
time  to  verify  that  the  system  has  been  restored  to  serviceability. 

(2)  Criteria. 

(a)  The  average  tlae  for  operators  and  aaintalners  to 
accomplish  assigned  system  maintenance  tasks  must  be  within  the  times  required 
by  the  maintenance  allocation  charts  (MAC)  contained  in  the  draft  technical  - 

manuals . 


(b)  The  mandatory  portion  of  the  unit  combat  PLL  must 
support  the  howitzers  during  IS  days  of  combat  operations. 

(c)  The  howitzer  must  be  recoverable  by  the  designated 
recovery  vehicle,  for  recovery  situations  up  to  and  including  fender  depth 
mire.  The  HIP  howitzer  must  be  capable  of  being  towed  by  like  vehicles  and/or 
by  the  FAASV  (in  emergency  conditions)  for  distances  of  at  least  15  kilo¬ 
meters,  without  damage  to  either  vehicle  and  without  requiring  special  tools 
or  equipment. 


(d)  All  required  tools,  TMDE,  TMs,  repair  parts, 
maintenance  personnel  and  their  equipment,  must  be  transportable  in  vehicles 
organic  to  the  units  at  each  maintenance  level. 

(e)  Test  measurement  and  diagnostic  equipment  (TMDE); 
including  the  howitzer's  built-in-test  (BIT),  built-in-test  equipment  (BITE), 
and  intermediate  level  maintenance  test  program  sets;  must  correctly  fault 
detect  to  at  least  95  percent  efficiency  and  isolate  equipment  faults  to  a 
line  replaceable  unit  (LRU)  to  at  least  90  percent  efficiency  of  those  faults 
they  are  capable  of  detecting. 

(f)  The  maintenance  tasks^ssslgned  to  the  unit  and 
intermediate  levels  of  maintenance,  by  means  of  the  unit  and  intermediate  TMs, 
will  accurately  reflect  "unit"  type  and  "Intermediate”,  type  maintenance  tasks. 

(g)  The  SSP  (including  all  tools,  calibration 
equipment,  repair  parts,  TMs,  and  support  items,  as  well  as  a  listing  of 
personnel  and  training  requirements,  and  descriptions  of  the  maintenance 
concept,  expendable  supplies  snd  equipment,  and  fixed  facilities)  must  permit 
accomplishment  of  all  supply  snd  maintenance  tasks  required  to  correct 
expected  operational  failures. 

(h)  The  TMs  must  be  prepared  1AW  M1L-M-63036A,  M1L-M- 
63038B,  MIL-HDBK-63038-1/2. 

(3)  Rationale.  This  Issue  subjectively  examines  logistics 
eupportablllty  as  opposed  to  the  quantitstlve  assessment  performed  In  the  RAM 
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lfiua<  The  planned  logistics  support  system  Bust  be  compatible  with  current 
forward  support  doctrine  and  the  Aray  logistics  systea.  Achievement  of 
criteria  will  demonstrate  that  HIP  units  can  be  fully  supported  when  fielded. 

(4)  Source.  DA  PAM  700-50,  Testing  for  Supportabillty; 
TRADOC  letter.  Subject:  Logistics  Supportabillty,  Logistics  Test  and 
Evaluation,  26  Sep  83;  TRADOC  PAM  525-27-2,  USA  Operational  Concept  for 
Recovery  and  Evacuation. 

b.  Issue  14.  Does  the  HIP  unit's  ammunition  resupply  system 
provide  sufficient  ammunition  for  the  HIP  howitzer? 

(1)  Scope.  The  tactical  scenario  will  stress  the  unit's 
ammunition  resupply  capability  for  providing  the  required  numbers  and  types  of 
fuzes,  projectiles,  propelling  charges,  and  prlaers.  Ammunition  resupply  will* 
be  conducted  during  periods  of  reduced  visibility,  under  varied  terrain 
conditions,  during  day  and  night  operations,  and  in  various  NBC  alsslon- 
oriented  protective  postures,  up  to  and  including  MOPP  IV.  The  unit's 
ammunition  resupply  system  Includes  the  ammunition  vehicles'  hauling 
capacities,  the  numbers  and  skills  of  ammunition  handling  personnel,  and  the 
unit's  standing  operating  procedures.  This  issue  evaluates  the  system's 
capability  for  providing  sufficient  ammunition  to  meet  the  requirements  of  the 
OMS/MP  for  the  twenty-four  hour,  wartime  weighted  average. 

(2)  Criteria.  The  unit's  ammunition  resupply  systea  must 
provide  the  HIP  howitzers  with  301  complete  rounds  per  tube  per  day. 

(3)  Rationale.  An  ammunition  resupply  rate  of  301  complete 
rounds  per  tube  per  day  is  based  on  an  analysis  of  the  SCORES,  Europe  I, 
Sequence  1IA  scenario  and  is  required  for  meeting  the  expected  threat.  The 
Increased  firepower  capability  of  the  HIP  howitzer  in  combination  with  the 
requirements  of  the  OMS/MP  brings  expanded  demands  for  ammunition.  The 
ammunition  resupply  systea  must  be  able  to  satisfy  this  demand  without 
requiring  major  additions  of  equipment  and  personnel  resources.  The  ammuni¬ 
tion  vehicles  and  personnel  resources  available  in  the  HIP  TOE  are  expected  to 
satisfy  these  requirements* 

(4)  Source.  L0A,  Annex  A,  Para.  4f(4)(b). 
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QPEfATlgHAL  FUi. 

a.  General.  The  operational  plan  of  the  HIP  Is  compatible  with  Field 
Artillery  doctrine  as  described  In  FM‘s-6-1,  6-20,  6-20-1,  6-20.-2  and  6-50 
but  Is  expected  to  cause  some  modi fixations  In  roles,  tactics  and  techniques 
described  In  those  manuals  because  of  the  Improved  capabilities  of  the  HIP  as 
compared  to  previous  models  of  the  M109  howitzer.  The  HIP  operational  plan 
Is  compatible  with  operational  concepts  addressed  In  the  Army  86  and  Airland 
Battle  2000  concepts. 

b.  Employment. 

(1)  Divisional  and  separate  brigade  HIP  battalions  and  armored 
cavalry  regimental  HIP  batteries  are  organized,  manned,  and  equipped  to  perform 
the  direct  support  (DS)  standard  tactical  mission.  The  battalion  Is  also 
capable  of  performing  the  other  standard  tactical  missions  of  reinforcing  (R ) , 
general  support-reinforcing  (GSR),  and  general  support  (GS )  plus  nonstandard 
tactical  missions.  Task  organization  of  .H109A3E2/E3  support  elements  allows 
for  accomplishment  of  tactical  missions  by  a  HIP  battery  when  accompanied  by 
Its  slice  of  the  support  structure.  A  HIP  battery  My  perform  a  mission 
independent  of  Its  parent  unit  (e.g.,  DS,  while  Its  parent  battalion  remains 

In  a  reinforcing  role).  Additionally,  centralized  tactical  control  makes 
possible  cross  attachment  of  firing  platoons  during  localized  surge  periods. 

(2)  As  part  of  the  field  artillery  system,  H109A3E2/E3  battalions 
will  also  be  found  within  Corps  Artillery  where  they  will  augnwnt  the  fires 
of  divisional  units  during  surge  periods  or  In  the  attack  of  high  density 
targets. 


C.-  Operational  Deployment. 

(1)  The  HIP  Is  operationally  deployed  to  pqovlde* dlr,ect  support 
fires  to  committed  units  within  the  division  sector.  A  divisional  field 
artillery  battalion  Is  habitually  placed  In  direct  support  of  a  maneuver 
brigade.  HIP  units  are  normally  deployed  In  firing  platoon  position  areas 
with  support  centralized  In  a  battery  support  area.  Platoon  position  areas 
will  be  1000-4000  meters  apart.-  Platoons  are  further  deployed  so  that  an 
Individual  H109AX2/E3  operates  within  an  assigned  area  as  large  as  1000 
meters  In  diameter.  The  platoon  headquarters  will  direct  dispersion  adequate 
to  Insure  that  no  two  howitzers  are  deployed  within  a  single  counterfire 
footprint.  An  alternate  positioning  technique  to  reduce  vulnerability  In- an 
environment  of  Intense  local  hostilities  Is  the  placement  of  two  howitzer 
sections  In  close  proximity  to  provide  eutual  support.  Close  positioning  of 
•11  four  fire  units  In  each  platoon  Is  also  possible  If  the  ground  threat  Is 
•ore  serious  than  vulnerability  to  enemy  counterfire.  HIP  batteries  and 
Subordinate  fire  units  will  be  located  In  depth  between  3  and  15  kilometers 
behind  the  forward  line  of  troops  (FlOT).  Specific  distances  will  vAry  with 
the  tactical  situation,  the  mission  of  the  supported  maneuver  force,  and  the 
terrain. 
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(2)  Displacement  options  available  to  and  employed  by  KIP  units  are 
•s  discussed  In  FH's  6-20-1  and  6-50.  The  option  selected  reflects  consider¬ 
ations  of  the  overall  tactical  situation,  Immediate  and  future  requirements 
of  the  supported  unit,  the  characteristics  of  the  terrain  to  be  traversed/ 
•occupied,  the  distances  Involved.  and_ the  anticipated  threat  enroute. 

•  ^  •*  i  -  *  *  —  •-  ■—  •  »  . 

(a)  The  H109AI2/E 3  battalion  and  subordinate  elements  will 
normally  displace  .by  echelon,  trlth  the  lowest  level  of  control  being  the 
platoon.  Time  and  tactlca.1  situation  permitting,  advance  parties  for  position 
and  survey  point  selection  are  dispatched  prior  to  initiation  of  movement. 

These  parties  will  normally  be  small  with  minimum  security.  The  Positioning 
and  Azimuth  Determining  System  (PADS)  will  be  used  to  establish  battery/platoon 
survey  points  and  update  points  along  routes  of  march.  Individual  howitzers 
will  have  the  capability  to  use  on-board  equipment  to  navigate  to  selected 
positions.  Convoy  elements  will  be  small,  thereby  reducing  any  identifiable 
Signature  and  the  Interruption  of  support  to  maneuver  forces. 

(b)  Emergency  /survivability  displacements  by  an  Individual  howi.tzer 
within  Its  assigned  position  area  will  be  conducted  on  order  and/or  In 
accordance  with  unit  policy  as  dictated  by  the  tactical  situation  or  the 
Intensity  of  the  threat.  Reconnaissance  of  alternate  positions  Is  not 
Mndatory  due  to  HIP's  position  determination  capability  and  the  ability  of 
the  howitzer  to  fire  from  any  position  offering  operational  safety. 

(c)  Because  of  this  Increased  flexibility  for  movements  by 
Individual  howitzers,  the  unit  ammunition  resupply  vehicles  (ARY)  have  a 
requirement  to  be  equipped  with  an  on-board  comunl cation  capability  as  well 
as  a  vehicle  navigation  aid  system.  These  capabilities  will  facilitate  the 
resupply  of  avnunltlon  from  ARY  to  howitzer. 


(3)  KIP  units  are  organized  and  equipped  to  perform  limited  self- 
defense.  «M1e  the  greater  dispersion  of  the  howitzer  battery  will  normally 
preclude  the  establishment  of  effective  defensive  perimeters,  pi  1  firing* 
operations  can  take  place  without  crew  members  leaving  the  Improved  armor 
protection  of  the  howitzer,  greatly  enhancing  survivability.  Operating  in 
this  semi -autonomous  mode,  outside  the  protection  offered  by  the  current 
battery  perimeter,  also  dictates  that  the  ammunition  and  command  and  control 
vehicles  supporting  the  HIP  oust  be  equipped  with  the  same  level  of  armor, 
mobility  and  self-contained  operational  capability  as  the  HIP.  A  night 
vision  device  for  the  howitzer  driver  assists  In  providing  self  defense  by 
•nhanclng  the  vehicle's  capability  to  move  during  periods  of  limited  visibility. 
Confrontation  with  anything  larger  than  small  dismounted  enemy  units,  however, 
*111  require  calling  by  radio  for  assltance  or  quickly  moving  to  break  contact. 
On-board  communications  will  make  early  warning  possible  and  allow  HIP  fire 
units  to  move  when  substantial  combat  forces  pose  a  threat. 
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d .  Cogwunjcatl ons  Support  Requirements. 


(1)  general .  SINC6ARS,  •  developmental  communications  system.  Is 
expected  to  support  the  bulk  of  the  HIP  communications  requirement.  SPCGAAS 
Is  the  new  faelly  of  securable,  jam  resistant,  VHF-FH  tactical  radios  that 
will  replace  the  current  AR/YRC-12  series  radios  beginning  In  1985. 

(2)  Cxtemal  communications.  The  HIP  battalion  end  subordinate 

batteries  will  have  the  capability  to  communicate  with  higher  headquarters 
through  VHF/FM  radio,  both-volce  and  digital -secure.  Voice  nets  do  not 
significantly  d1ffer*frdm  those  addressed  1n'FM'6-l.  OlgltaV  coommlcatlon 
nets  will  be  similar  to  those  outlined  In  Appendix  E,  FH  6-20.  The  SINCCARS, 
with  appropriate  communications  security  equipment,. will  be  the  primary 
communications  means  for- these  nets.  - 

(3)  Internal  communications .  The  HIP  battalion  communicates 
internally  via  SlfCiARS  to  the  battery,  platoon  and  fire  unit  level.  Hire 
communication  is  used  within  headquarters,  TOC  and  support  areas  and  to 
provide  backup  conmuni cat ions  with  the  fire  units.  Nets  parallel  those 
addressed  In  FM  6-1. 
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155am  Howitzer  Improvement  Program 
Operational  Mode  Summary /Nission  Profile 


1.  Purpose .  This  report  provides  the  operational  mode  summa¬ 
ry  /mis’sToir'p ro file  for  the  armament  subsystem  of  the  M1C9E5  HI? 
equipped  with  a  modified  (i.e.,  M203  compatible)  M185  cannon.  Data 
provided  Includes: 

a.  Mission  Profile  CMP); 

b.  Operational  Mode  Summary  (OMS); 

c.  Charge  profile. 

2 .  Def ini tions  . 


a.  Mission  Profile  (MP)--A  measure  of  the  level  of  effort  (in 
rounds,  miles.  No.  of  communications,  etc.)  a  system  can  be  expected 
to  exert  under  various  levels  of  combat  intensity.  MP  consists  of 
banded  estimates  for  different  levels  of  combat  intensity.  For  this 
study,  three  levels  are  used: 

(1)  Sus tained--The  level  of  combat  a  system  will  experience  40 
555  of  the  time  it  is  committed.  This  is  the  least  demanding  level. 

(2)  Inter.se--The  level  that  occurs  30  -  455  of  the  time; 

(3)  Surge--The  level  that  occurs  5  -  155  of  the  time.  This  is 
the  most  demanding  level. 

b.  Operational  Mode  Summary  (OMS)--A  single  measure  of  level  c 
effort  developed  as  a  weighted  arithmatic  mean  across  all  three 
levels  of  combat  intensity. 

c.  Charge  Profile-~A  relative  frequency  distribution  shewing  t 
propellant  charges  fired  by  the  force. 

3 .  Assumptions . 

a.  The  variability  in  combat  intensity  across  the  front  ar.d 
between  repetitions  will  approx ima te  '  the  variability  across  time. 

b.  Only  conventional  munitions  are  available. 

c.  Survivability  moves  are  made  every  three  missions. 

d.  Average  distance  traveled  on  a  survivability  move  is  750 
meters. 
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e  . 

No  high  angle 

fire. 

Para 

2  •  +  £  r  5  , 

a  . 

Weapon  System 

:  M109E5  (HIP)  with  modified  M185 

cantor.. 

b. 

Scenario: 

SCORES ,  EUROPE  V. 

c . 

Data  Source: 

Target  Acquisition/Fire  Support 
US  Army  Field  Artillery  School. 

Model  (TAFSM) 

d. 

Prepared  By: 

Major  John  C.  Traynham 

Concepi .  and  Studies  Division, 
US  Army  Field  Artillery  School 
Ft.  Sill,  Oklahoma  73503-5600 
Phone:  (Av)  659-4491/4974 

DCD 

5.  Methodoloev. 


a.  Mission  Profile. 

(1)  I'ue  Target  Ac qui s i t ion /Fire  Support  Model  (TAFSM  )  was  used 
to  generate  ammunition  expenditures  and  the  distribution  of  rounds 
fired  by  gun-target  range. 

(2)  The  total  nucber  of  rounds  fired  by  each. 155mm  howitzer  was 

then  extracted  and,  where  necessary,  scaled  to  24-hours.  This  data 
was  then  subjected  to  a  T1 e t jen-Moore  test  (  *  0.1)  to  identify 

possible  outliers. 

(3)  Firing  levels  for  sustaining  and  surge  periods  were  deter¬ 
mined  by  using  the  time  percentages  as  weapon  percentiles  when  weapon 
were  ordered  by  total  rounds  fired.  The  expenditures  of  the  bour.dar 
weapons  were  taken  as  the  bounding  values  for  the  specified  level  of 
combat.  Intense  levels  were  taken  as  the  values  between  maximum 
sustaining  and  minimum  surge  expenditures. 

Example:  Sust aining--40  to  55X  of  the  time 

40th  percentile  weapon  •  Wpn  No.  37 
*  55th  percentile  weapon  •  Wpn  No.  51 

The  rounds  expended  by  the  38th  and  51st  weapons  (when  ordera 
by  rounds  fired)  become  the  bounded  estimate  for  Sustaining. 

(4)  Due  to  the  nature  of  the  data  ,  final  values  were  subjected 
to  substantial  rounding. 

b.  Operational  Mode  Summary.  The  OMS  is  a  weighted  mean  of  th< 
Mission  Profile.  (Note:  Due  to  the  variability  of  the  data,  the  0M! 
may  not  be  a  valid  point  estimate  of  overall  combat  intensity.)  In 
computing  OMS,  duration  mid-points  of  sustained  and  Intense  levels 
were  used.  The  computational  formula  is: 

• 

OKS  -  P  *R  -f  P  *R.  +  0 . 1 5*R  ; 

..v _  as  ii  su 


w 
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P  •  Mean  proportion  of  time  in  sustaining  (aid-point); 

R*  ■  Mean  No.  of  round s /Km /bo ve s  in  sustaining; 

P*  •  Mean  p-nportion  of  time  in  intense  (mid-point); 

R*  •  Mean  No.  of  round s /Km /move s  fired  in  intense; 

R>u  “  Mean  No.  of  rounds /Km/moves  fired  in  surge. 

e.  Charge  distribution.  Total  rounds  fired  ‘for  each  gun-target 
range  were  extracted.  The  ranges  were  then  used  to  determine  the 
charge  required  to  achieve  that  range  (low-angle  fire  only).  The 
total  number  of  each  type  of  charge  that  was  consumed  was  calculated 
as  well  as  its  percentage  of  the  total.  Two  cases  were  used  in 
determining  the  charges  required: 

(1)  Case  1:  The  minimum  possible  zone  was  selected.  Criteria 
for  going  to  a  higher  zone  was  when  a  target  was  within  1000  meters  of 
a  given  zone's  maximum  range. 

(2)  Case  2:  The  maximum  possible  zone  was  selected  subject  only 
to  a  minimum  elevation  of  120  mils.  The  criteria  for  going  to  a 
higher  zone  was  as  above. 

6 .  Analysis . 

a.  Unit  firing  rates  varied  from  a  minimum  of  78  rounds  to  a 
maximum  of  628.  The  mean  expenditure  was  388.1  rounds /weapon /i ay  with 
a  standard  deviation  of  137.0.  There  were  no  outliers. 

b.  The  bulk  (682)  of  the  weapons  expended  between  400  and  550 
rounds;  the  modal  class  was  400  -  425  rounds  and  contained  272  of  the 
weapons..  Weapons  falling  outside  of  this  range  were  approximately 
uniformly  distributed.  (Chart  1) 

c.  Differences  between  the  previous  CKS/MP  and  the  one  contained 
herein  appear  reasonable  and  within  the  limits  to  be  expected  based  on 
the  change  in  scenarios  and  differences  in  weapons  and  force  structure. 

d.  Since  moves  are  primarily  a  function  of  rounds  and  missions 
(survival  moves  dominate  tactical  moves  in  this  scenario,  in  both 
numbers  and  distance  traveled),  mobility  data  follows  a  similar 
distribution^ 

7 .  155mm  Operational  Mode  Suama ry /Ml s s ion  Profile 

a.  Mission  Profile. 


Level 

Firepower  * 

Mobility2 

Sustained 

40  -  80  Missions 

13 

-  25 

Moves 

(40  -  552) 

200  -  400  Rounds 

10 

*•  # 

-  25 

Km. 

Intense 

75  -  115  Missions 

25 

-  40 

Moves 

(30  -  452) 

400  -  550  Rounds 

20 

-  40 

Km  . 

Surge 

110  -  140  Missions 

35 

-  50 

Moves 

(  5  -  152) 

550  -  650  Rounds 

25 

-  50 

Km 
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Per  tube  per  day 

Includes  survivability  move  ever'.  2  -  4  missions 

b.  Oparatier. al  Mode  Summary. 

(1)  Firepower:  83  Mi s s i on s / Tu be  'Day 

411  Rcunds/Tube/Day 

(2)  Mobility:  28  Moves/Weapon /Day 

25  Km /Weapon/Day 

c.  Charge  Distribution. 


Case 

CB 

WB 

Ml  19 

Maximum  Zone 

132 

652 

122 

Minimum  Zone 

282 

502 

122 

M2  2 3 


io: 


£  £  £ 
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Forma:  for  Letter  of  Agreement,  Required  Operational  Ca¬ 
pability.  Joint  Service  Operational  Requirements.  Utter  Re¬ 
quirement.  and  Training  Device  Requirement.  LOA.  ROC. 
JSOR.  LR.  and  TDR  will  be  in  the  format  below.  Limit 
information  to  that  necessary  for  an  HQDA  decision.  The 
basic  document  should  not  exceed  four  pages  In  the  LOA. 
me  less  detail  and  bands  of  broader  performance  than  in  the 
ROC,  LR.  and  TDR.  The  JSOR  will  initially  have  broader 
h«wt«  of  performance.  As  the  development  process  contin¬ 
ues.  these  bands  of  performance  should  become  more  nar¬ 
row.  Terms  in  each  paragraph  of  the  LOA  will  evolve  into 
more  specific  terms  in  the  ROC.  LR,  and  TDR.  Attach  the 
mission  profiles  to  the  LOA  as  an  annex. 

1.  TWO. 

a.  Give  a  descriptive  title  for  the  program. 

b.  Add  CARDS  Reference  Number  (ODCSOPS  will  as¬ 
sign  this  -lumber). 

2.  Nssd/thrast. 

State  what  is  needed.  Briefly  describe  the  threat  and  oper- 
abonal/traimng  deficiency  need  for  the  system.  Include  the 
enemy's  capability  to  detect,  identify,  locate,  avoid,  sup¬ 
press.  destroy .  or  otherwise  counter  the  system .  Describe  the 
responsive  threat  over  time  to  support  evolutionary  develop¬ 
ment  when  applicable. 

3.  Tima  frame  and  IOC. 

List  the  time  frame  for  the  LOA  and  IOC  for  the  ROC.  LR, 
JSOR,  and  TDR.  Include  dates  of  successive  models  when 
known. 

4.  OparatlonaLorgan izatlonal  plan. 

In  a  bnef  paragraph  state  the  following: 

a.  How  the  equipment  will  be  used. 

b.  Deployment  requirements. 

c.  Geographical  areas  of  use. 

d.  Weather  and  climatological  factors  to  be  considered 
during  equipment  operations. 

t.  Battlefield  conditions  (such  as  ECM.  smoke,  and  dust) 
in  which  the  system  will  operate. 

/.  The  type  of  units  that  will  use  and  support  the  equip¬ 
ment.  Attach  the  Operational  Mode  Summary/Mission  Pro¬ 
file  to  the  LOA  as  an  annex . 

8.  Essential  characteristics. 

Describe  only  the  main  operational  features  of  the  system. 
Included  are  counter-countermeasure  capabilities,  health 
and  physical  security,  safety,  environmental  quality  control. 
HFE  requirements,  transportability  and  reliability,  availabil¬ 
ity,  and  maintainability.  Performance  must  be  responsive  to 
battlefield  environmental  conditions  of  continuous  combat 
(such  as  full  ECM.  smoke  aerosols,  electromagnetic  envi¬ 
ronmental  effects  (E3),  rain,  fog,  haze,  and  dust).  Perfor¬ 
mance  and  reliability  characteristics  will  be  expressed  in 
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bands  of  performance.  Those  which  are  not  suitable  for 
banding  will  be  stated  as  a  single  value.  During  develop¬ 
ment,  commercial,  other  service,  NATO  or  other  allied  na¬ 
tion  characteristics  of  existing  or  programed  systems  should 
be  considered  for  inclusion.  This  will  be  with  a  view  toward 
establishing  the  basis  for  interoperability,  coproduction,  or 
standardization.  Bands  of  performance  should  oe  flexible 
enough  to  consider  competing  systems  of  other  services  or 
allied  nations.  The  stated  bands  of  performance  or  single 
value  characteristics  will  be  adjusted  only  after  the  combat 
and  the  materiel  developers  agree  that  such  changes  are 
necessary.  DCSOPS  will  approve  changes  for  documents 
previously  approved  by  DCSOPS  Changes  to  all  other  doc¬ 
uments  will  be  made  jointly  by  TRADOC  and  DARCOM 
The  requirements  and  provisions  for  the  following  must  be 
considered: 

a.  Interoperability. 

b.  Continuity  of  Operations  (CONOPSi 

c.  Security. 

d.  Transportability 

e.  Reliability,  availability,  and  maintainability 

/.  Standardization,  including  commonality  for  hardware 
and  software  to  which  the  system  will  adhere 

g.  Nuclear  survivability,  non-nuclear  survivability  NBC 
contamination  and  decontamination  survivability 

h.  Individual  and  collective  protection  equipment 

i.  Adverse  weather  and  reduced  visibility  conditions 
(smoke  and  obscurants),  operations,  and  military  operations 
on  urbanized  terrain,  where  applicable 

j.  Communications. 

k.  Airdrop  certification  and  jumppack 

l.  Preplanned  product  improvements  (para  3-31) 

6.  Technical  aaeessment. 

in  the  LOA.  divide  this  paragraph  into  operational,  techni¬ 
cal,  logistical,  safety,  health.  HFE.  energy  consumption, 
training,  personnel,  and  manpower  subparagraphs  in  each 
subparagraph  describe  what  the  combat  and  matenel  devel¬ 
opers.  logistician,  training  developer,  and  personnel  man¬ 
ager  must  undertake  to  produce  the  total  system  Include  a 
listing  of  major  events  and  dates.  In  the  ROC.  include  a  bnef 
paragraph  about  the  technical  effon  required  Address  major 
areas  for  full  scale  development  in  terms  of  scope,  technical 
approach,  and  associated  nsks  in  high,  medium,  low.  or 
similar  categories.  For  NDI.  bnefly  outline  planned  market 
survey  effon  and/or  military  suitability  evaluations 

7.  Logistic  support  plan. 

Briefly  describe  the  logistic  suppon  plan  Include  statement 
that  the  logistic  suppon  plan  will  be  available  for  evaluation 
during  OT  1  (if  LOA)  or  for  testing  dunng  OT  II  (if  ROC. 
JSOR.  LR.  or  TDR). 

t.  Training  asssssmsnt. 

Discuss  the  need  for  system  TDs.  When  required,  include 


device  description  as  an  annex  to  the  ROC  or  LR  NET 
operator  and  maintenance  personnel  training,  technical  man¬ 
uals  (TM),  and  training  materiel  requirements  will  be  stated 
in  terms  of  needs  for  both  institutional  and  unit  training. 
Include  a  statement  that  the  training  support  plan  will  be 
available  for  evaluation  during  OT  1  (if  LOA)  or  for  testing 
during  OT  U  (if  ROC.  LR.  JSOR.  or  TDR). 

9.  Manpoworlorco  structure  ssssssmsflL 
Estimate  manpower  requirements  per  system,  using  unit, 
and  total  Army  by  component  (Active.  ARNG.  USAR). 
Identify  manpower  savings  resulting  from  replaced  systems . 
if  any.  Include  a  statement  which  will  require  an  assessment 
of  alternatives  to  reduce  manpower  requirements  and  an 
assessment  of  force  structure  implications  resulting  from 
system  inclusion  in  the  total  force  by  component.  If  the  force 
structure  assessment  exceeds  current  programed  force  struc¬ 
ture  levels,  then  identification  of  force  structure  trade-offs 
within  mission  area  or  mission  elements  are  required.  Trade¬ 
off  analysis  should  be  addressed  to  the  degree  necessary  to 
bring  the  force  structure  assessment  within  current  program¬ 
ing  levels,  if  possible. 

10.  Standardization  and  interoperability. 

Discuss  other  Service.  NATO,  and  other  foreign  interest  in 
the  program,  identify  similar  programs  contemplated  by  oth¬ 
er  Services.  NATO,  or  other  allies. 

11.  Life  cycle  coat  asaasamant. 

Add  life  cycle  cost  assessment  as  appendix  I  to  the  require¬ 
ments  documents.  Provide  total  life  cycle  costs  using  mainly 
summary  parametric  estimating  techniques.  State  the  major 
life  cycle  phases  of  RAD  investment  nonrecurring,  invest¬ 
ment  recurring,  and  operation  and  support.  Also,  include  the 
design  to  cost  goals.  As  much  as  possible,  show  the  estimat¬ 
ed  cost  of  major  items  or  components  below  the  system 
level.  (These  data  should  be  consistent  with  the  MSRS  and 
BCE 

12.  Mllaatona  achadula. 

Provide  a  listing  of  significant  events  with  dates  to  occur 
between  approval  of  document  (LOA.  LR.  ROC,  TDR,  and 
so  forth)  and  the  next  scheduled  IPR.  The  following  should 
hr  included  ROC.  LR.  TDR.  LOA  approval,  program  man¬ 
agement  documentation  (PMD).  DT.  OT.  other  test  (Mar- 
IsetfUser  Survey  for  NDI),  and  IPR. 

Mmmx  A — Coordination. 

List  all  major  commands,  other  Services,  allied  nations  and 
activities  with  whom  the  LOA.  ROC.  LR.  TDR  and  JSOR 


was  coordinated.  Provide  full  rationale  for  nonacceptance  of 
comments,  if  any. 

Annex  B  —  Operational  Mode  Summery/Mieeion 
Profile  Annex. 

List  tasks  and  conditions  for  frequency  and  urgency  viewed 
for  system  employment  in  military  operations.  The  mission 
profile  is  logically  derived  from  the  operational  and  training 
concept.  It  provides  the  starting  point  for  developing  the 
system  characteristics. 

Annex  C—  COEA  Annex. 

Executive  summary  of  the  COEA.  Classify  as  required 
Withdraw  after  HQ,  TRADOC  approval  of  the  requirements 
documents  and  handle  as  a  separate  document  for  transmittal 
as  needed. 

Annex  D — Rationale  Annex. 

Support  various  characteristics  stated  in  the  LOA.  ROC. 
JSOR.  LR,  and  TDR.  This  provides  an  audit  trail  and  ratio¬ 
nale  for  determining  how  the  characteristics  were  derived 

Annex  E— RAM  Rationale  Annex. 

Executive  summary  of  the  RAM  Rationale  Report  contains 
guidance  on  the  preparation  of  both  the  RAM  Rationale 
Report  Annex  and  RAM  Rationale  Report. 

Annex  F— Training  Device  Annex. 

(When  required).  Include  description  of  needed  TDs  A  sep¬ 
arate  annex  is  required  for  each  TD  The  following  format 
will  be  used: 

1.  Title. 

2.  Operational/Organizational  Plan 
3  Essential  characteristics. 

4.  Technical  assessment. 

5.  Logistical  assessment. 

6.  Training  assessment. 

7.  Manpower  assessment. 

8.  Funding 


Notes: 

1.  Withdraw  all  annexes  except  annexes  A  and  B  before  forwarding  an 
LOA  to  HQDA 

2.  Withdraw  all  annexes  except  annex  A  before  forwarding  an  LR.  ROC. 
JSOR.  oe  TDR  to  HQDA 

3.  Include  only  annex  A  when  distributing  the  approved  document 

4.  Send  the  BOIP/QQPRI  with  the  ROC  and  TDR  when  they  are  sent  to 
HQDA  for  approval  When  the  BOIP'QQPRI  are  not  submined  with  the 
requirements  documents,  the  transmittal  letter  will  contain  a  statement 
about  the  projected  submission  date 
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APPENDIX  F 

SAMPLE  FROM  A  QUALITATIVE  AND  QUANTITATIVE  REQUIREMENTS  INFORMATION  (QQPRI) 

DOCUMENT 
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Qualitative  and  Quantitative  Personnel  Requirements 
Information  (QQPRI)  for  POWER  PLANT  ELEC:  15KW  400HZ  SSDED, 

LIN:  250245,  NETP  No.  TS  84-26 

1.  REQUIREMENT  INFORMATION: 

a.  Requirement  or  Procurement  Directive:  ROC  f/SSDED  Gen  Sts  15-60kW  appd 
850703. 

b.  Type  Classification  (TC)  Date:  8(0930. 

c.  First  Unit  Equipped  Date  (FUED):  900930. 

d.  Army  Modernization  Information  Memorandum  (AMIM)  Number:  A763. 

e.  QQPRI  Preparer:  SSG  Harold  F.  Kinch,  2  Feb  87,  U.S.  Army  Troop  Support 
Command,  ATTN:  AMSTR-MSE,  4300  Goodfellow  Boulevard,  St.  Louis,  MO  63120-1798, 
AUTOVON  693-0646. 

2.  DESCRIPTION  AND  DIRECT  PRODUCTIVE  ANNUAL  MAINTEANNCE  MAN-HOURS  (DPAMMHs ) : 

a.  Principal  Item:  LIN:  250245  -  POWER  PLANT  ELEC:  15KW  400HA  SSDED. 

The  SSDED  POWER  PLANT  will  consist  of  two  (2)Gen  Sets  15  KW  400  HZ  SSDED,  LIN 
229543  mounted  on  two  (2)  military  M200A1,  2H  ton  trailer  with  connecting  cables, 
mounting  hardware  and  ancillary  equipment. 

b.  Component  Major  Item: 

(1)  LIN:  229537  -  GEN  SET  15KW  400HZ  (SSDED). _ 

MOS  UL  IDS  IGS 

44B 

5 2D  132  100  50 

NOTE:  DPAMMHs  for  this  item  were  estimated  by  Major  Subordinate  Command  based 
on  similar  items  of  equipment. 

(2)  LIN:  E02807  -  CHASSIS  TRAILER:  GEN  2 h  TON  M200A1. 


MOS 

UL 

IDS 

ICS 

63B 

63W 

NOTE: 

32 

DPAMMHs  for  this  item  were 

20 

taken  from  the  Manpower 

Requirements  Criteria 
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Total  DPAMMHs  by  MOS,  SSI,  or  OPMCS  for  subparagraphs  a  and  b  above: 

(1)  Developmental  Items: 

UL  IDS  IGS 

132  100  50 

(2)  Type  Classified  Items: 

UL  IDS  J£S 

32 

20 

Associated  Support  Items  of  Equipment  (ASI0E):  NA. 

I 

3.  NUMBER  DIRECT  OPERATORS  REQUIRED  TO  CREW  OR  OPERATE  EQUIPMENT:  No  additional 
personnel  will  be  required  to  operate  or  man  the  SSDED;  existing  sources  will 

be  used. 

4.  DUTY  POSITIONS  BY  DESCRIPTIVE  TITLE: 

Position  Title  Suggested  Placement 


Operator: 

General  Purpose  User  (GPU) 

Any  MOS 

UL: 

Power-Generation  Equipment  Repairer 

MOS  5 2D 

Light-Wheel  Vehicle  Mechanic 

MOS  63B 

IDS: 

Metal  Worker 

MOS  44B 

Power-Generation  Equipment  Repairer 

MOS  5 2D 

Wheel  Vehicle  Repairer 

MOS  63V 

IGS: 

Metal  Worker 

MOS  44B 

Power-Generation  Equipment  Repairer 

MOS  5 2D 

5.  INDIVIDUAL  UNIQUE 

DUTIES,  TASKS,  AND  CHARACTERISTICS: 

a.  MOS  44B  performs  duties  and  tasks  as  listed  in  AR  611-201. 

b.  MOS  52D  performs  duties  and  tasks  as  listed  in  AR  611-201. 


MOS 

44B 

52D 

MOS 

63B 

63W 
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c.  MOS  63B  perform*  duties  and  tasks  as  listed  in  AH  611-201. 

d.  MOS  63W  performs  duties  and  tasks  as  listed  in  AR  611-201. 

6.  NI TP  NUMBER  AND  NET  TRAINING  BASE  REQUIREMENTS: 

a.  NETP  Number:  TS  84-26. 

b.  Training  will  be  accomplished  with  the  SSDED  Skid  Mounted  Generator 
Sets. 
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TRAINING  IMPACT  WORKSHEET 
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APPENDIX  H 

SAMPLE  FROM  A  BASIS  OF  ISSUE  PLAN  (BOIP) 
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APPENDIX  I 

SAMPLE  FROM  A  "SUPPORT  ITEM  UTILIZATION  SUMMARY" 
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APPENDIX  0 

CLUSTER  ALGORITHMS  FROM  WHEATON,  FINGERMAN,  AND  BOYLAN  (1975) 
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ALGORITHM  1 - GENERALI Z ABILITY 


INPUT  ARRAYS 

Let  X  *  txsj]  be  the  job  objective-behavioral  element 
matrix,  arrangea  so  that  objectives  in  the  same  cluster  are 
contiguous.  X  has  I  rows,  corresponding  to  job  objectives; 
in  the  present  case  I  *  266.  X  has  J  columns  corresponding 
to  behavioral  elements* 

Let  C  [ck]  be  a  K-by-1  vector  containing  the  number  of 
job  objectives  in  each  of  the  K  clusters.  In  the  present 
ease  K  *  16.  The  entries  in  C  are  ordered  consistently  with 
the  order  of  clusters  in  X.  The  values  of  each  ck  for  the 
present  case  may  be  computed  from  data. 

WORKING  ARRAYS 

Let  D  *  [dj]  be  a  J-by-1  vector  containing  the  fre¬ 
quency  with  which  each  of  the  J  behavioral  elements  occurs 
across  the  entire  set  (or  domain)  of  job  objectives. 

Let  F  *  Ifkjl  be  a  K-by-J  matrix  containing  the  frequency 
with  whicK  each  of  the  J  behavioral  elements  occurs  within 
each  of  the  K  clusters  of  job  objectives. 

Let  W  »  Iwfcj]  be  a  K-by-J  matrix  which  contains  the 
generalizability  weight  for  each  element  in  each  cluster. 

OUTPUT  ARRAYS 

Let  G  «  (gil  be  an  I-by-1  vector  containing  generalizability 
index  values  for  each  of  the  I  job  objectives. 

OPTIONS 

Let  R  «  (ri)  be  an  I-by-1  vector  containing  the  rank  of 
the  generalizability  index  value  for  the  ifcb  job  objective, 
ranking  being  performed  independently  within  each  cluster. 

Let  Z  *  (zj.)  be  an  I-by-1  vector  containing  the  stan¬ 
dardized  generalizability  index  value  for  the  i*h  job  objec¬ 
tive,  standardization  being  performed  wtihin  each  cluster  using 
the  within-cluster  mean  and  standard  deviation  for  the  gj.'s 
in  that  cluster. 
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POINTERS  AND  INDEX  VARIABLES 

i  ranges  from  1  to  I  across  the  I  job  objectives  (e.g. 
rows  of  X) * 

j  ranges  from  1  to  J  across  the  J  behavioral  elements 
(e.g.  columns  of  X)* 

k  ranges  from  1  to  K  across  the  K  clusters  (e.g.  rows  of 
F) . 

LL  "lower  limit"  pointer,  used  to  indicate  the  lowest  job 
objective  in  a  given  cluster. 

_UL  "upper  limit"  pointer,  used  to  indicate  the  highest 
job  objective  in  a  given  cluster. 
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COMPUTING  ALGORITHM  NO.  1 


Step 

1.) 

For  j  :*  1  to  J, 

dj  =-  i  Xij_ 
i-l 

Step 

2.) 

Comment:  D  vector  is  now 

computed . 

Step 

3.) 

LL  :«  1. 

Step 

4.) 

UL  :* 

Step 

5.) 

Comment:  LL  and  UL  define 
limits  of  Cluster  1. 

the 

lower 

and 

upper 

Step 

6.) 

k  :  =  1. 

Step 

7.) 

For  j  :*  1  to  J, 

UL 

fki  !=  1  xi j ' 

KJ  i=LL  J 

Step 

8.) 

wkj  -  <fkj  **  2)/V 

If  k  «  K  GO  TO  Step  14. 

Step 

9.) 

LL  ■*  LL  ^  Ck* 

Step 

10.) 

k  :*  k  +  1. 

Step 

11.) 

UL  :*  UL  +  ck. 

Step 

12.) 

Comment:  LL  and  UL  define 
limits  of  Cluster  k. 

the 

lower 

and 

upper 

Step 

13.) 

GO  TO  Step  7. 

Step 

14.) 

k  :*  1. 

Step 

15.) 

i  :«  1. 

Step 

16.) 

UL  •  * 
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Step  17.) 

gi  !*J1 

Step  18.) 

i  :«  i  +  1. 

Step  19.) 

If  i  GT  I  GO  TO  Step  24. 

Step  20.) 

If  i  LE  UL  GO  TO  Step  17. 

Step  21.) 

k  :«  k  *  1. 

Step  22.) 

UL  :  ■  UL  +  c)c* 

Step  23.) 

GO  TO  Step  17. 

Step  24.) 

Output  G  =  [g^] . 

Optional 

Step  25.) 

LL  :=  1. 

Step  26.) 

k  :=  1. 

Step  27.) 

Execute  Algorithm  RANK  (  G  (LL) ,  c^,  R  (LL)  ) . 

Step  28.) 

Comment:  Algorithm  RANK  ranks  c^  values  beginning 
in  address  G(LL) ,  and  places  the  ranks  in  array 

R  beginning  at  address  LL. 

Step  29.) 

Execute  Algorithm  STANDARD  (  G  (LL)  ,  c^,  Z^(LL)  )  . 

Step  30.) 

Algorithm  STANDARD  computes  standard  score  values 
for  the  Cfc  scores  beginning  in  address  G (LL) , 
and  places  them  in  array  Z  beginning  at  address 

LL. 

Step  31.) 

k  :*  k  +  1. 

Step  32.) 

If  k  GT  K  GO  TO  Step  35. 

Step  33.) 

LL  z *  LL  ^  c  |  ^ ^ j  ^  1 • 

Step  34.) 

GO  TO  Step  27. 

Step  35.) 

Output  R  “  (r^J . 

Step  36.) 

Output  Z  «  [z^l  . 

Step  37.) 

STOP 
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ALGORITHM  2 - ELEMENT  COVERAGE 


INPUT  ARRAYS 

Let  X  =  I^ij]  be  the  job  objective-behavioral  element 
matrix.  X  has  I  rows,  corresponding  to  job  objectives;  in 
the  present  case,  I  «  266.  X  has  J  columns  corresponding  to 
behavioral  elements* 

Let  £  *  [sn]  be  an  N-by-1  vector  listing  the  job  objec¬ 
tives  in  the  sample  to  be  analysed.  Each  entry  in  S  is  a  row 
number  in  the  matrix  X  that  corresponds  to  a  job  objective 
included  in  the  sample. 

WORKING  ARRAYS 

Let  D  ■  [dj]  be  a  J-by-1  vector  containing  the  frequency 
with  which  each  of  the  J  behavioral  elements  occurs  across 
the  entire  domain  of  job  objectives. 

Let  F  *  [f jl  be  a  J-by-1  vector  containing  the  frequency 
with  which  each  of  the  J  behavioral  elements  occurs  within 
the  sample  of  objectives  to  be  evaluated. 

Let  D'  «  [djl  be  a  J-by-1  vector  which  indicates  which 
elements  occur  at  least  once  across  all  job  objectives  in  the 
domain,  that  is,  if  dj  is  greater  than  or  equal  to  1,  then 
dj  equals  1;  otherwise  dj  equals  0. 

Let  F'  «  ffj]  be  a  J-by-1  vector  which  indicates  which 
elements  occur  at  least  once  in  the  sample  of  job  objectives 
being  analysed.  Thus,  fj  equals  1  when  fj  is  at  least  1, 
and  fj  is  0  otherwise. 

OUTPUT  STATISTICS 

Let  PROP  be  the  proportion  of  behavioral  elements  which 
occur  in  the  domain  (X)  and  also  in  the  sample. 

Let  CHISQ  be  a  measure  of  goodness-of-f it  between  the 
frequency  with  which  an  element  occurs  in  the  domain  and  in 
the  sample.  CHISQ  will  be  distributed  as  chi-square  under  a 
null  hypothesis  that  the  frequencies  in  the  domain  and  sample 
are  perfectly  associated;  it  will  have  J»1  degrees  of  free¬ 
dom  (DF  in  the  algorithm)  in  the  present  case  (J-l) ,  since 
all  J  elements  occur  at  least  once  in  the  domain.  CHISQ  may 
be  tested  for  significance  ("poorness  of  fit"). 
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Let  PHIMAX  be  a  measure  of  correlation  between  the  fre¬ 
quency  with  which  an  element  occurs  in  the  domain  and  in  the 
sample  .  Zt  is  derived  directly  from  CHISQ. 


POINTERS 

i  ranges  from  1  to  I  across  the  I  job  objectives  (e.g. 
rows  of  X) • 

j  ranges  from  1  to  J  across  the  J  behavioral  elements 
(e.g.  columns  of  X) • 

n  ranges  from  1  to  N  across  the  N  job  objectives  in  the 
sample  (e.g.  rows  of  S) . 
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COMPUTING  ALGORITHM  NO.  2 


Step  1.) 

For  j  :*  1  to  J, 

I 

di  1  xii*  ! 

J  j=i  XJ 

Step  2.) 

Comment:  D  vector  is  now  computed. 

Step  3 . ) 

For  j  :*  1  to  J, 

N 

fi  Z  xs  i 

3  sn3* 

n=l 

Step  4 . ) 

Comment:  F  vector  is  now  computed. 

Step  5.) 

For  j  :*  i  to  J,  execute  Steps  6  and  7. 

Step  6.) 

If  d .  GE  1  d\  :*  1  ELSE  d^  :=  0. 

Step  7.) 

If  fj  GE  If!  :=  1  ELSE  f^  :=  0. 

Step  8.) 

J  J 

PROP  :«[  I  (d!  *  f  1 1  /  I  d!. 

j-1  3  3  j«l  3 

Step  9.) 

For  j  :■  1  to  J, 

dj  dj  *  (N/J) * 

Step  10. } 

J  2 

CHISQ  Z  I (f s  -  d . ) *  /  d . ] #  for  d.  t  0. 

j  -  1  3  3  3  3 

Step  11.) 

J 

DF  Z  d!  -  1. 

j-1  3 

Step  12.) 

J 

PHIMAX  SORT  [  CHISQ  /  (  Z  f.)  /  (DF)  ]. 

j-i  3 

Step  13.) 

OUTPUT  PROP#  CHISQ#  DF,  PHIMAX. 

Step  14 . ) 

STOP 

E2-J-8 


MANPRINT  METHODS  MONOGRAPH: 

AIDING  THE  DEVELOPMENT  OF  MANPOWER-BASED  SYSTEM  EVALUATION 

CONCEPT  PAPER  FOR  PRODUCT  FIVE  -  OPERATIONS  AND  MAINTENANCE  JOBS  PREDICTION  AID 

Lanny  K.  Walker,  Cecil  D.  Johnson,  and  David  L.  Payne,  Hay  Systems,  Inc. 

Carl  F.  Aslala,  Perceptronlcs,  Inc. 

CONTENTS _ 


Page 

OVERVIEW .  E3-5 

Introduction  .  E3-5 

Problems  .  E3-5 

Objectives  .  E3-6 

Product  Objectives  .  E3-6 

Concept  Paper  Objectives  .  E3-7 

Scope .  E3-8 

Technical  Concept  .  E3-8 

The  Aggregation  Process .  E3-10 

Broad  Principles  Shaping  Design.. .  E3-10 

Summary  of  Output .  E3-13 

Summary  of  Required  Input  .  E3-13 

BACKGROUND  .  E3-14 

The  Acquisition  Process  .  E3-14 

Present  Methods  .  E3-17 

PRODUCT  DEVELOPMENT  .  E3-18 

System  Approach  Stages  . E3-18 

Concept  Development  Stage  .  E3-18 

Design  Specification  Stage  .  E3-19 

Production  of  Finished  Product  Stage  .  E3-19 

DATA  REQUIREMENTS .  E3-20 

Product  Five .  E3-20 

Essential  Development  Characteristics  .  E3-20 

DATA  REQUIREMENTS  AND  SOURCES .  E3-22 

Major  Data  Categories  .  E3-22 

Task  Identification  Description  .  E3-24 

Design  Data  .  E3-24 

Comparable  Systems  Data  .  E3-25 

Task  Clustering  Criteria  and  Measures  .  E3-26 

Task  Interrelationships  and  Initial  Constraints  .  E3-26 

Clustering  Measures:  Competencies  .  E3-27 

Baseline  Systems  Information  . .  E3-28 

Technology  Complexity  Information  .  E3-29 


E3-1 


Manpower  and  Personnel  Management  Information  .  E3-29 

School  and  MOS  Boundaries  .  E3-30 

Personnel  Rates  .  E3-30 

CLASSES  OF  INFORMATION  .  E3-31 

Architectural  Design  .  E3-31 

Modules  and  Module  Components  .  E3-31 

The  Data  Bank  and  Working  Files  .  E3-31 

The  Model  Bank:  Decision  Models/Aids  .  E3-33 

User  and  System  Interactions .  E3-36 

Menu  of  Models  and  Decision  Aids  .  E3-36 

The  Sequence  of  Events  .  E3-36 

The  Alternative  Sequences  .  E3-36 

Module  Logic  and  Internal  Process  .  E3-37 

Task  Identification  and  Task  Data  Generation  .  E3-37 

Aggregation  of  Job  Components  .  E3-38 

The  Role  of  the  Constraint  Matrix  .  E3-39 

The  S/U  Measure  .  E3-41 

Functional  Definition  at  Developmental  Level  3  .  E3-48 

A  General  Description  of  the  Algorithm  for  Optimizing  the  S/U 

Gain  .  E3-48 

The  Overall  Aggregation  Process  .  E3-49 

PRODUCT  DESIGN  .  E3-49 

The  Information  and  Aids  of  the  Product  .  E3-49 

Data  Base  (DB)  Information  .  E3-49 

Decision  Aids  for  the  Use  of  DB  Files  .  E3-49 

Decision  Aids  for  the  Generation  of  Task  Data  .  E3-53 

Decision  Aids  for  Taking  an  Analyst  Through  an  Analytic  Process  ....  E3-53 

Product  Five  Models  .  E3-53 

The  Information  Needs  of  the  Analyst  .  E3-54 

Information  Provided  by  Product  Five  .  E3-54 

Task  and  Data  Generation  Methodology  .  E3-55 

Task  Data  Requirement  .  E3-55 

Task  Generation  Capability  .  E3-55 

Analysis  of  Critical  Tasks  .  E3-56 

Task  Analysis  Hierarchy  .  E3-57 

Task  Analysis  Generation  .  E3-57 

Network  Methodology  .  E3-58 

Workload  Generator  .  E3-59 

Perceptronics  MPN  Workload  Model  .  E3-59 

Uses  of  the  MPN  Models  .  E3-59 

Job  Component  Aggregation:  Measures  and  Algorithms  .  E3-63 

The  Methodological  Confidence  Continuum— From  the  Fully  Determined 

to  the  Relatively  Unknown  .  E3-63 

The  Rank  Order  is  Important  .  E3-64 

Alternative  Approaches  Considered  and  Rejected  .  E3-64 

Technological  Complexity  .  E3-66 

Measurement  of  Technological  Complexity  .  E3-67 

Use  of  Technological  Complexity  in  the  Aggregation  Process  .  E3-68 

The  Role  of  Technological  Complexity  in  the  Aggregation  Process  ....  E3-68 
Opportunities  for  Job  Engineering  .  E3-69 


F3-2 


POSSIBLE  EXPANSION  CAPABILITIES  .  E3-69 

Training  Transfer  .  E3-69 

The  Proposed  Approach  .  E3-70 

The  Algorithm  .  E3-71 

Training  Transfer  Effect  as  a  Component  of  the  S/U  Measure  .  E3-71 

Learning  Decay  Rate  .  E3-73 

Importance  Weighting  -  Advantages  and  Disadvantages  . .  E3-74 

Maximizing  the  relationship  of  the  S/U  Measure  to  the  Underlying 

Utility  Function  .  E3-74 

The  Metric  .  E3-74 

The  Analyst's  Estimate  .  E3-74 

The  Role  of  Importance  Weights  in  Computing  the  S/U  Measure  .  E3-74 

ACCEPTABILITY,  USABILITY,  AND  USER  WORKLOAD  .  E3-75 

A  Hierarchy  of  Design  .  E3-75 

The  Expandability  Capability  .  E3-75 

Determination  of  School  and  MOS  Boundaries  .  E3-76 

Design  and  Development  of  Data  Base  Files  .  E3-77 

I/O  Relationships  with  Product  Six  .  E3-78 

Product  Five  Interations  in  Response  to  Product  Six  Results  .  E3-78 

The  Zero  Level  of  S/U  Development  -  Development  Level  Zero  .  E3-79 

TRAINING  OF  USERS  .  E3-80 

Protocol  Following  .  E3-81 

Quasi -Expert  System  .  E3-82 

Adaptive  Training  .  E3-82 

Logical  Integration  of  the  Concepts  .  E3-82 

Summary  of  Training  the  User .  E3-83 

Software  Specification  and  Documentation .  E3-83 

Software  Functional  Description  .  E3-83 

Training/User's  Guide .  E3-83 

INSTITUTIONALIZATION  .  E3-84 

Acceptance  and  Implementation  .  E3-84 

MPT  Product . . .  E3-84 

System  Transfer .  E3-84 

Implementation  of  Solution  Approach .  E3-85 

REFERENCES  .  E3-86 


LIST  OF  TABLES 

Table  1.  Comparison  of  the  S/U  Measure  Across  Development 

Levels  .  E3-46 

2.  The  Four  Data  Bank  Files  .  E3-52 

3.  Modified  Petri  Net  (MPN)  Capabilities  for  Operator 

Combat  Task  Analysis  .  E3-63 


E3-3 


LIST  OF  FIGURES 


Figure  1.  Schematic  for  Product  Five  .  E3-9 

2.  Aggregation  Model  .  E3-11 

3.  The  Aggregation  Process  in  the  Context  of  Product  Five  .  E3-12 

4.  System  Acquisition  Process  .  E3-15 

5.  Product  Five  Compared  to  HARDMAN/MIST  .  E3-21 

6.  New  Concepts  for  Product  Five  .  E3-23 

7.  Product  Five  Design  . E3-32 

8.  Product  Five  Models  &  Decision  Aids  .  E3-34 

8.  Product  Five  Models  &  Decision  Aids  (cont'd)  .  E3-35 

9.  Clustering  Criteria  .  E3-40 

10.  Definition  of  the  S/U  Variable  .  E3-43 

11.  Selected  S/U  Measure  .  E3-45 

12.  Overall  Aggregation  Process  .  E3-50 

13.  Aggregation  of  Job  Components  .  E3-51 

14.  Rank  Order  of  Aggregation  Variables  .  E3-65 

15.  Three  Computational  Examples . * .  E3-72 


E3-4 


Concept  Paper  for  Product  Five-- 
Operations  and  Maintenance  Job  Prediction  Aid 

OVERVIEW 


INTRODUCTION 

A  general  problem  that  must  be  solved  to  aid  the  Army  in  developing  and 
acquiring  systems  that  can  be  manned  adequately  is  that  of  determining  how  to 
evaluate  hardware  and  software  plus  training  designs  (prior  to  the  development 
of  a  prototype)  so  that  manning  requirements  and  alternative  training 
strategies.  Interface  and  function  allocation,  and  tactical  solutions  can  be 
determined  and  provided  to  Army  decision  makers. 

The  concept  for  a  product  which  will  aid  MANPRINT  personnel  in  predicting 
the  operations  ?,id  maintenance  jobs  required  with  respect  to  a  given  system 
and  the  number  of  operations  and  maintenance  personnel  per  job  per  system  is 
described.  The  purpose  of  this  product  is  to  determine  the  number  of 
personnel  (per  job)  required  to  operate  and  maintain  system  hardware  so  that 
the  Army  has  a  basis  to  evaluate  personnel  availability. 

Product  Five  Is  defined  as  a  software  suite  Including  a  set  of  decision 
aids  and  models  embedded  in  a  common  software  environment  (a  model  bank);  a 
data  bank;  working  files;  and  user  Interface  software. 

Data  input  sources  are  identified.  State-of-the-art  computerized  models 
with  user  friendly  interface  are  proposed.  An  approach  to  job  component 
aggregation  that  can  be  compared  to  a  linear  programming  model  is  set  forth. 

The  major  decision  processes  supported  by  the  product  are:  (1)  task  and 
task  data  generation;  (2)  task  and  duty  model  aggregation  Into  larger  jobs  or 
job  components;  (3)  workload  determination;  and  (4)  generation  of  a  report  on 
manpower  and  personnel  requirements.  Personnel  using  this  product  will 
require  access  to  Initial  hardware  and  software  interface  designs, 
mission-function  task  analyses,  battlefield  conditions  and  performance 
criteria. 

This  paper  presents  a  conceptualized  design  of  an  operation  and  main¬ 
tenance  jobs  prediction  aid.  Application  of  this  MANPRINT  aid  will  provide  an 
Imposed  process  for  evaluating  new  system  acquisitions  impact  on  Army  manning. 

PROBLEMS 


The  Army  must  ensure  that  its  soldiers  will  be  able  to  operate  and 
maintain  system  hardware  and  software  to  a  level  of  performance  sufficient  to 
achieve  mission  success.  During  the  past  several  years,  ARI  has  convincingly 
demonstrated  to  the  Army  that  this  goal  is  possible  only  when  manpower, 
personnel,  and  training  issues  (MPT)  are  considered  early  in  the  acquisition 
process  -  during  the  system  design  stages. 

Presently,  little  attention  Is  paid  to  MPT  issues  during  system 
acquisition.  Consequently,  systems  are  frequently  fielded  which  cannot  be 
satisfactorily  manned  or  for  which  performance  does  not  measure  up  to 
specifications.  MANPRINT  Is  a  set  of  guidelines,  regulations,  procedures, 
methods  and  processes  that  attempts  to  maximize  the  probability  that  systems 
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are  developed  and  acquired  which  can  be  effectively  operated  and  maintained  by 
available  numbers  of  future  soldiers  having  varied,  but  identifiable,  skills 
and  capabilities. 

There  are  two  general  problems  that  must  be  solved  to  aid  the  Army  in 
Insuring  that  It  Is  developing  and  acquiring  systems  that  can  be  manned 
adequately: 

(a)  Determining  how  to  develop  and  communicate  information  to  materiel 
developers  that  will  influence  hardware  and  software  design  so  that 
resulting  systems  can  be  manned  and  can  achieve  mission  success  with 
available  soldiers. 

(b)  Determining  how  to  evaluate  hardware  and  software  plus  training 
designs  (prior  to  the  development  of  a  prototype)  so  that  manning 
potentials  and  alternative  training.  Interface  and  function 
allocation,  and  tactical  solutions  (in  the  presence  of  manning 
deficits)  can  be  determined  and  provided  to  Army  decision  makers. 

This  concept  paper  for  Product  Five  addresses  problem  area  (b)  discussed 
above.  Any  solution  tc  this  problem  must  be  sufficiently  complete  so  as  to 
provide  a  useful  aid  to  the  Army.  Therefore,  the  solution  of  three  specific, 
procedural  problems  Is  required.  These  are: 

(1)  How  are  the  various  required  classes  of  information  provided  by  the 
product  developed  at  the  detailed,  working  level? 

(2)  Where  will  the  required  data  (for  the  development  of  this 

Information)  be  obtained? 

(3)  How  can  the  use  and  acceptance  of  the  product  that  attempts  to 
answer  these  problems  be  Insured?  That  is,  who  should  be  using  the 
product  and  in  what  manner  should  communication  take  place? 


OBJECTIVES 

Developing  information  that  affects  designs  and  evaluating  designs 
require  that  Army  personnel  make  difficult  decisions.  By  the  end  of  this 
program,  ARI  will  have  finished  products  that  aid  personnel  in  making  those 
decisions.  The  personnel  being  aided  will  have  experience  in  the  domains  to 
which  the  decision  aids  apply,  but  it  cannot  be  assured  that  they  will  have 
any  computer  experience.  Product  Five  cannot  require  the  creation  of  new 
organizations,  nor  can  its  use  absorb  large  numbers  of  additional  person 
hours.  The  objective  is  to  improve  the  acquisition  process  by  aiding  the 
personnel  that  work  currently  In  that  process.  The  specific  decision-aiding 
product  that  ARI  wants  at  the  conclusion  of  this  program  is  a  product  to  aid 
In  evaluating  system  designs. 

Product  Objectives.  Product  Five  is  a  product  to  aid  in  evaluating 
system  designs.  It  is  to  be  used  following  the  initial  detailed  interface 
design,  but  prior  to  the  decision  to  fund  the  hardware  and  software  prototype. 
Product  Five  will  aid  MANPRINT  personnel  in  predicting  the  operations  and 
maintenance  jobs  required  and  the  number  of  operations  and  maintenance 
personnel  per  job  per  system.  The  purpose  of  this  product  is  to  determine  the 
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number  of  personnel  (per  job)  required  to  operate  and  maintain  system  hardware 
so  that  the  Army  has  a  basis  to  evaluate  personnel  availability.  User's  of 
Product  Five  will  have  access  to  initial  hardware  and  software  interface 
designs,  mission-function-task  analyses,  battlefield  conditions,  and 
performance  criteria.  It  should  be  stressed  that  the  requirement  to  be 
identified  Is  at  the  job,  not  the  MOS,  level.  The  goal  of  this  specific 
product  is  to  determine  numbers  of  required  personnel  per  system  that  can  be 
associated  with  clusters  of  functions  and  tasks  (both  operations  and 
maintenance). 

If  computer  hardware  Is  required  for  the  product  to  be  developed  or  used, 
It  must  be  hardware  that  is  in  residence  at  appropriate  Army  locations,  or 
scheduled  to  be  acquired  by  those  locations,  or  accessible  via  secure  networks 
and  lines  to  those  locations. 

Concept  Paper  Objectives.  This  program  is  being  conducted  In  three 
stages.  As  each  stage  Is  completed,  that  stage's  deliverables  (concept 
papers,  design  specifications,  finished  products)  will  become  the  property  of 
the  U.S.  Army.  This  report  provides  the  results  of  the  concept  paper  stage  of 
the  program. 

The  objectives  of  this  concept  paper  for  Product  Five  are  to  discuss  and 
describe,  at  a  high  level  of  detail,  the  following  significant  issues: 

(1)  How  Product  Five  will  be  developed. 

(2)  What  data  will  be  required  for  Product  Five. 

(3)  Where  all  required  data  are  now  found  or  will  be  found. 

(4)  What  classes  of  Information  and/or  aiding  Product  Five  will  provide. 

(5)  How  all  information  and/or  aiding  to  be  provided  will  be  produced  by 
Product  Five. 

(6)  How  Product  Five  will  Insure  the  acceptability  and  usability  of  its 
output.  This  will  include  identification  of  the  most  fruitful  users 
of  each  product  by  organization,  job  type,  and  acquisition  cycle 
phase,  and  the  methods  of  communication  required  to  Insure  user 
acceptability. 

(7)  How  Product  Five  will  train  Its  users. 

(8)  The  number  of  person-hours  required  to  use  Product  Five  for  major 
acquisitions. 

(9)  The  means  for  achieving  institutionalization  of  Product  Five  within 
the  Army  organizational  context,  as  it  now  exists. 

After  a  brief  discussion  of  the  scope  and  a  summary  of  the  technical 
concept,  each  of  these  critical  issues  are  discussed  in  the  major  sections  of 
this  concept  paper  report. 
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SCOPE 


This  concept  paper  describes  Product  Five  of  this  MANPRINT  effort,  which 
will  aid  in  the  estimation  of  quantitative  manpower  and  personnel  requirements 
for  systems  under  development.  We  will  first  provide  a  description  of  the 
family  of  decision  aids  and  models  and  associated  data  bases  which  make  up 
this  product,  along  with  the  architecture  for  integrating  them  into  a 
user-friendly  configuration.  We  will  then  describe  the  means  for  developing 
the  product,  and  both  selected  and  non-selected  candidate  methodologies 
considered  for  inclusion  in  the  product  will  be  discussed.  Such  design  and 
benefit  considerations  as  the  availability  of  the  required  input  data,  the 
developmental  and  user  variables,  design  and  developmental  risks,  and  the 
expected  benefits  to  the  Army  will  be  presented  and  critically  examined. 
Also,  the  manner  of  installing  the  product,  training  users,  and  assuring  the 
acceptability  of  the  product  to  both  analysts  and  managers  will  be  discussed. 
In  short,  the  paper  presents  a  product  description  and  additional  information 
which  together  will  provide  a  basis  for  evaluating  the  probable  technical 
validity  and  usefulness  of  Product  Five  as  a  justification  for  its  further 
development  and  implementation. 

TECHNICAL  CONCEPT 

The  conceptualized  design  for  Product  Five  can  be  described  in  terms  of 
its  major  modules  as  depicted  in  Figure  1.  The  major  decision  processes 
accomplished  by  the  product  are:  (1)  task  and  task  data  generation,  (2)  task 
and  duty  module  aggregation  into  larger  jobs  or  job  components,  (3)  workload 
determination,  and  (4)  generation  of  an  output  report  on  manpower  and 
personnel  requirements.  Certain  modules  and  data  inputs  are  identified  as 
optional  for  the  analyst.  For  example,  if  tasks  are  already  identified  with 
adequate  task  descriptions  available  from  another  source,  the  analyst  may 
choose  to  exercise  the  option  of  discontinuing  the  use  of  baseline  systems. 
Similarly,  the  analyst  may  either  use  or  delete  the  module  which  can  provide 
information  on  the  relationship  of  tasks  to  MOS  and  school  boundaries.  Other 
analyst  options  are  provided  by  the  clustering  criteria  which  can  be  modified 
to  reflect  the  type  of  new  system  being  evaluated,  whether  operator  or 
malntainer  tasks  are  under  consideration,  and  whether  tasks  are  being 
aggregated  into  duty  modules  or  duty  modules  into  jobs.  The  analyst  will  be 
given  the  option  of  successively  relaxing  constraints  after  examining  the 
product  output  (manpower  personnel  requirements  in  terms  of  number  of  jobs, 
soldiers  required  for  each  job  and  workload  per  job). 

Of  the  processes  accomplished  by  the  product,  that  of  task  age  egation  is 
the  one  which  is  accomplished  in  the  least  satisfactory  rnann*'  coday  by  a 
MANPRINT  analyst  making  use  of  HARDMAN  or  MIST.  (Essentially,  these 
techniques  are  restricted  in  HARDMAN  and  MIST  to  a  judgmental  assignment  of 
tasks  to  MOS.)  Also,  It  would  appear  that  there  are  more  credible  alternative 
approaches  to  task  aggregation  as  compared  to  the  alternatives  available  to 
the  other  major  decision  processes  noted  above.  For  these  reasons  this  report 
will  introduce  the  task  aggregation  approach  earlier  and  will  provide  more 
discussion  of  alternative  approaches  to  task  aggregation  --  as  compared  to  the 
other  decision  processes. 
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The  Aggregation  Process,  The  product  decision  aid  proposed  for  implemen¬ 
tation  includes  an  approach  to  job  component  aggregation  that  can  be  compared 
to  a  linear  programming  model.  This  comparison  is  made  in  Figure  2.  Job 
component  interactions,  relationships,  organizational  and  supervisory 
boundaries,  work  locations,  and  other  considerations  can  result  in  some 
mandatory  combinations  of  tasks  into  task  clusters  and  in  the  identification 

of  other  clusters  that  must  not  be  aggregated.  In  the  latter  case,  pairs  of 

job  components  that  are  ineligible  for  aggregation  with  each  other  are 
recorded  as  zeros  In  a  constraint  matrix  of  zeros  and  ones.  A  measure  of 
similarity  among  job  components  that  bears  on  the  utility  of  aggregating  a 
pair  of  job  components  into  a  single  cluster  is  referred  to  throughout  this 
report  as  a  S/U  measure.  This  S/U  measure  compares  with  the  objective 
function  of  a  linear  programming  model. 

The  aggregation  process,  considered  in  context  of  other  closely  related 
processes  and  Product  Five  outputs.  Is  summarized  in  Figure  3.  This  process 
will  be  much  more  carefully  described  later  in  the  report.  This  summary  is 
Introduced  at  this  point  to  aid  the  reader  in  his  understanding  and  evaluation 

of  design  issues  pertaining  to  the  product  when  considered  as  a  total  system. 

Broad  Principles  Shaping  Design.  In  developing  this  design  for  the 
Implementation  of  Product  Five,  emphasis  has  been  placed  on  the  following 
principles: 

(a)  The  design  will  maximize  the  probability  t!iat  Product  Five  can  be 
successfully  developed,  installed,  and  utilized;  the  risk  that  the 
product  will  not  achieve  design  goals  will  be  minimized. 

(b)  The  design  will  make  use  of  all  relevant  variables;  the  selection  of 
a  convenient  subset  of  variables  —  convenient  in  that  they  are 
readily  available,  appear  to  be  objective,  or  are  amenable  to 
simulation  process,  but  which  are  not  sufficiently  representative  of 
the  variables  that  predict  the  desired  utility  measures  —  will  be 
avoided. 

(c)  An  undue  workload  on  the  analyst  will  not  be  imposed  by  the  design 
—  either  by  input  requirements,  or  by  the  decisions  required  of  the 
analyst. 

(d)  The  bases  of  all  Product  Five  decisions  must  be  understandable  to 
the  analyst  and  he  should  be  encouraged  to  use  his  intuitive 
expertise. 

(e)  The  aiding  provided  to  the  analyst  by  the  embedded  decision  models 
should  reflect  what  a  computer  can  do  better  than  a  human:  assessing 
the  data  bank,  the  analysis  of  large  numbers  of  comparisons, 
computations  that  are  unwieldy  or  time  consuming,  and  of  course,  all 
tedious  clerical  operations. 

(f)  The  design  will  avoid  the  use  of  techniques  that  provide  the 

appearance  of  objectivity  and/or  sophistication  when  these 

techniques  fail  to  provide  the  real  essence  of  objective  data  or 
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AGGREGATION  MODEL 
Analogy  with  a  Linear  Programming  Model 


Model 

Linear  Programming  Model 

Aggregation  Model 

Utility 

Function 

Objective  Function 
(Linear  Definition) 

Similarity/Utility 

Measure  (Non-linear 

Cost  Minimization; 

Cost  Reduction 

Times  (-1)) 

Constraints 

Algebraic  Definition 
(Usually  expressed  as  a 

Set  of  Inequalities) 

Rule  Based 

(Task  Interactions  and 

Relationships  Plus 

Organizational/Physical 

Taboos) 

Optimization 

The  Objective  Function  is 
Maxmized  (or  Minimized) 
and  a  Constrained  Solution 
then  Sought,  as  in  Brogden- 
Weaver  Algorithm,  or,  as  in 
Simplex  Algorithms, 
Successively  more  Optimal 
Solutions,  Each  within  the 
Constrained  Space,  are 
Sought 

Only  Mergers  Meeting 

All  Restraints  are 

Considered;  all  Eligible 
Pairings  are  Tried  Out  with 
the  Pair  Which  Maximizes 
the  Utility  Function  Selected 
at  Each  Step.  The  Number 
of  Job  Components  Under 
Consideration  is  Reduced 
by  One  at  Each  Iteration 

FIGURE  2 
Aggregation  Model 
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DECISION  PROCESS 

OUTPUT  TO  PRODUCT  SIX 

iL  Aggregate  Tasks  into  Duty  Modules  Using 
Community  of  Required  Competencies  as 
the  Simularity/Utility  (S/U)  Measure  to  Drive 
Clustering  Process  -  within  Constraints 
based  on  Organizational,  Physical,  and 

Time  Restriction  Task  Relationships,  plus 
other  Task  Interactions.  Stopping  of 

Clustering  Process  will  Occur  when  S/U 
Increment  is  Below  Threshold,  when 

Number  of  Clusters  has  been  Reduced  to 
Predetermined  Number,  or  Technological 
Complexity  Exceeds  Value  set  by  Analyst. 

Duty  Modules  Defined  by 

Constituent  Tasks  and  Task 
Descriptions. 

tL  Determine  Workload  Associated  with  Each 
Duty  Module. 

Not  Applicable 

C.  Determine  Duty  Position/jobs  and 
Recommended  MOS  to  Each  Job  Using 
Aggregation  Process  Described  in  a, 

Above.  Determine  Manpower/Personnel 
Requirements  by  Job. 

Jobs/Duty  Positions  Defined  in  Terms 
of  Duty  Modules;  Recommended  MOS 
for  Each  Job;  Workload  by  Job; 
Manpower/Personnel  Requirements 
in  Terms  of  Jobs. 

SL  At  Option  of  Analyst,  Determine  Current 

MOS  and  School  Curriculum  Boundaries 
as  Related  to  Job  Components;  Redetermine 
Jobs,  and  Recommended  MOS  for  Each 

Job  -  so  as  to  Minimize  Requirement  for 
Changing  MOS  Structure  and/or  School 
Curriculum.  Determine  Manpower/ 

Personnel  Requirements  by  Job. 

Above  Output,  as  in  a  Repeated,  but 
this  Time  also  Considering  MOS 
and  School  Boundaries  (that  in  Turn 
Reflect  Personnel  and  Training 
Availability). 

FIGURE  3 

The  Aggregation  Model  Process  in  the  Context  of  Product  Five 
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measurement  or  when  they  fail  to  provide  results  which  exceed  the 
validity  of  results  provided  by  less  sophisticated  (usually  more 
understandable  and  less  expensive  to  produce  and  use)  methods. 

Sumnary  of  Output.  All  tasks  of  the  new  system  being  evaluated  will  be 
identified  in  the  final  results  as  a  component  of  a  duty  module  and/or  a  job; 
in  turn,  each  duty  module  and  job  will  be  identified  in  terms  of  its 
constituent  tasks  and  the  characteristics  of  those  tasks. 

An  initial  summary  of  Product  Five  output  available  for  the  use  of 
Product  Six  (Personnel  Characteristics)  is  provided  by  Figure  3,  These 
outputs  provided  to  Product  Six  in  a  machine-usable  form  will  be  available  to 
the  analyst  with  additional  explanatory  information,  including  information 
that  will  clarify  the  process  that  led  to  a  particular  output.  Other 
Intermediate  outputs,  as  well  as  aids,  prompts,  and  access  to  data  bank,  will 
be  provided  to  the  analyst  to  permit  him  to  effectively  control  the  process 
and  to  intelligently  exercise  the  options  permitted  by  the  proposed  design. 

The  number  of  manpower  spaces  needed  to  accomplish  the  defined  jobs  will 
be  provided  in  the  Product  Five  output.  When  exactly  one  manpower  position  is 
to  be  associated  with  each  job  (or  duty  position  cluster  of  tasks),  the  number 
of  jobs  and  number  of  required  manpower  spaces  will  be  the  same.  In  other 
instances,  when  the  workload  for  a  given  task  cluster  is  greater  than  that 
which  can  be  accomplished  by  one  person,  for  example,  the  numb°r  of  "jobs"  and 
the  quantitative  manpower  requirements  may  be  different. 

Product  Five  will  also  provide  the  estimated  number  of  personnel  who  must 
be  in  the  Army  inventory  to  achieve  a  reasonable  assurance  that  the  estimated 
manpower  requirements  can  be  met.  These  personnel  estimates  will  make  use  of 
accepted  relationships  between  manpower  and  personnel  requirements,  taking 
into  consideration  the  various  reasons  that  people  in  the  Army  inventory  may 
be  unavailable  for  performance  in  operational  duty  positions.  The  model  will 
also  calculate  the  estimated  number  of  personnel  who  must  be  recruited  and 
trained  annually  to  compensate  for  expected  losses  from  the  required  personnel 
inventory. 

Summary  of  Required  Input.  It  is  understood  that  information  bearing  on 
task  identification  and  description  and  baseline  system  identification  (as 
required)  will  vary  from  little  more  than  engineering  drawings  and  specifi¬ 
cations  to  well-defined  task  lists  accompanied  by  HFE  data  on  each  task.  The 
proposed  product  will  permit  the  analyst  to  commence  at  either  point  without 
being  called  upon  to  redo  something  that  already  exists  or  being  stopped  cold 
because  the  available  information  is  inadequate  for  initiating  a  task 
generation  process. 

The  analyst  will  be  required  to  input  task  lists  with  coded  information 
bearing  on  task  characteristics.  Product  Five  will  furnish  recommendations 
and  aid  to  help  the  user  obtain  this  information  and  arrive  at  the  required 
coding.  (Since  the  information  pertaining  to  the  new  system  design  cannot  be 
counted  upon  to  arrive  in  a  standard  format  nor  to  arrive  with  a  consistent 
degree  of  completeness,  the  analyst  must  still  act  as  a  transducer  to  convert 
design  information  into  task  data.) 
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The  proposed  product  design  Includes  a  data  bank  containing  files  of 
competencies,  MOS  and  school  domain  information.  Data  must  be  collected  by 
the  product  developer  and  reviewed  by  Army  school  personnel  during  the  product 
development  phase.  The  development  of  this  data  bank  will  contribute  to 
developmental  cost,  but  will  be  rewarded  by  a  considerable  reduction  in  the 
demands  made  on  the  analyst. 


BACKGROUND 

The  Army  acquires  systems  as  a  mechanism  for  obtaining  needed  perfor¬ 
mance.  The  hardware  and  software  components  of  most  Army  systems  are  operated 
and  maintained  by  soldiers.  Therefore,  soldiers  are  components  of  those 
systems.  The  performance  and  availability  levels  of  systems  are  directly 
related  to  the  performance  of  the  soldiers  who  operate,  maintain,  and  support 
their  hardware  and  software. 

The  levels  of  characteristics  (aptitudes,  strength,  size,  etc.)  of  people 
vary  widely.  Some  levels  of  personnel  characteristics  exist  in  small 
percentages  of  the  population  that  are  not  readily  accessible  to  the  Army. 
Usually,  somebody  can  be  found  who  (given  enough  of  the  right  kind  of 
training)  can  do  whatever  is  required  to  operate  or  maintain  even  a  badly 
designed  system  to  required  levels.  Unfortunately,  training  resources  are  not 
infinite,  and  the  effects  of  training  on  performance  are  not  linear.  The 
bottom  line  is  that  people  who  can  do  anything  are  in  short  supply  and  in 
heavy  demand. 

The  Army  needs  to  Insure  that  its  soldiers  will  be  able  to  operate  and 
maintain  system  hardware  and  software.  It  is  particularly  critical  that 
soldiers  who  are  available  to  the  Army  in  required  numbers  be  able  to  achieve 
with  system  hardware  and  software  the  levels  of  performance  and  availability 
that  will  permit  mission  success. 

THE  ACQUISITION  PROCESS 

Figure  4  Illustrates  the  first  part  of  the  system  acquisition  process 
(through  Full-Scale  Development).  The  exhibit  lists  the  major  formal  products 
and  events  which  offer  opportunities  for  Manpower,  Personnel,  and  Training 
(MPT)  Input  through  Milestone  II  (ASARC  and  DSARC  II).  Organizational  and 
Operational  Plans  may  address  organizational,  equipment,  and  personnel 
tradeoffs  required  by  inclusion  of  the  system  in  the  total  force  structure, 
providing  input  to  the  Tentative  Qualitative  and  Quantitative  Personnel 
Requirements  Information  (TQQPRI).  The  TQQPRI  provides  the  most  current 
Information  concerning  the  numbers  and  qualifications  of  personnel  involved  in 
the  use,  support,  and  maintenance  of  the  proposed  system.  When  appropriate 
and  feasible.  It  describes  duties  and  tasks,  including  work  units,  performance 
standards,  recommended  MOS,  and  other  detailed  factors.  It  may  address 
Implications  for  personnel  selection  and  training  support.  The  final  version 
Is  prepared  during  Full-Scale  Development.  The  Tentative  Basis  of  Issue  Plan 
(TBOIP)  contains  unit  structure  and  issue  recommendations  which  have 
Implications  for  the  numbers  of  personnel  required  by  skill. 
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By  Milestone  I,  the  major  elements  of  the  design  which  will  derive  the 
MPT  requirements  for  numbers  and  skills  of  personnel  are  largely  frozen. 
Later  design  changes  can,  perhaps,  shorten  training  times  or  smooth  rough 
edges  of  the  design,  but  the  basic  structure  of  the  user  and  malntalner  tasks 
cannot  be  easily  changed.  MPT  consideration  is  required  prior  to  Milestone  I 
in  order  to  have  sufficient  impact  on  the  system  design. 

As  Indicated  In  Figure  4,  there  are  required  documents  which  provide  MPT 
design  Input  prior  to  Milestone  I.  However,  even  when  these  documents  are 
produced,  the  consideration  of  MPT  factors  is  based  largely  on  undisciplined 
subjective  assessments;  adequate  data  and  analytic  methodologies  are  not 
available.  Furthermore,  these  requirements  do  not  sufficiently  Influence  the 
design.  Some  of  the  major  reasons  for  this  are: 

(1)  Personnel  constraints  are  not  provided  in  language  and  detail  which 

the  system  designers  (the  PM  office  and  the  contractor)  can 

understand  and  use; 

(2)  Designers  do  not  believe  they  can  afford  to  trade  off  machine 
performance  to  meet  vague  personnel  skill  limitations; 

(3)  In  the  source  selection  process  the  values  assigned  to  Integrated 

Logistics  Support  (ILS)  —  which  includes  MPT  —  are  low;  and 

(4)  Performance  competitions  focus  largely  on  the  performance  of  the 

machine,  not  on  the  performance  of  the  man-machine  system. 

ARI  recently  completed  an  ambitious  project  to  analyze  these  problems  and 
determine  the  implications  regarding  the  acquisition  process  by  performing 
"Reverse  Engineering"  on  four  specific  systems:  Blackhawk,  MLRS,  Stinger,  and 
M-l  BITE.  The  major  types  of  MPT  problems  found  include  the  following: 

(1)  Human  factors  engineering  was  not  addressed  for  some  system 
components; 

(2)  0&0  concepts  were  often  incomplete  or  ill-founded; 

(3)  Manpower  levels  were  underestimated; 

(4)  Skill  and  ability  needs  were  undetermined  or  underestimated; 

(5)  Training  concepts  were  untested;  and 

(6)  Training  devices  were  unavailable. 

In  summary,  the  problems  fall  into  two  areas.  First,  data  and  methodol¬ 
ogies  are  not  available  tc  estimate  MPT  requirements  adequately,  in  sufficient 
detail,  and  with  sufficient  precision  to  enable  them  to  be  enforced.  Second, 
the  mechanisms  to  manage  the  development  and  integration  of  this  information 
are  not  fully  in  place.  The  aids  to  be  developed  in  the  present  procurement 
address  both  these  areas. 
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PRESENT  METHODS 


By  virtue  of  Its  requirements  and  resources,  the  Department  of  Defense 
has  been,  on  the  leading  edge  of  the  development  and  application  of  new 
technologies.  Weapon  systems  using  these  new  technologies  have  been  developed 
to  upgrade  or  replace  more  traditional  systems.  New  command  and  control  and 
weapon  systems  are  being  developed  to  counter  new  high-technology  threats  from 
potential  adversaries.  Of  all  the  armed  services,  the  Army  probably  feels  the 
greatest  Impact  of  the  technological  revolution  we  are  currently  experiencing. 
New  battlefield  command  and  control  systems,  computer-based  combat  operations 
centers,  and  complex,  computer-based  weapon  systems  are  placing  Increased 
demands  upon  those  who  are  the  users  of,  malntainers  of,  and  components  in 
these  increasingly  sophisticated  high-technology  systems. 

This  continually  Increasing  demand  upon  the  Army's  human  resources,  and  a 
corresponding  increasing  awareness  that  the  human  may  well  be  the  limiting 
factor  in  ultimate  system  performance,  has  led  to  the  development  of  several 
approaches  to  estimating  the  MPT  ’requirements  of  systems  In  the  materiel 
acquisition  process. 

One  of  these  systems,  the  Army  HARDMAN  (from  Hardware  vs.  Manpower)  Is  a 
procedure  for  bringing  hardware  and  manpower  considerations  into  better 
balance.  The  Army  HARDMAN  Comparability  Methodology  was  developed  to  provide 
credible  MPT  estimates  early  In  the  weapons  system  acquisition  process 
(Zimmerman,  Butler,  Gray,  Rosenberg,  and  Rlsser,  1984).  The  HARDMAN  approach 
Is  adapted  from  that  used  by  the  Navy  and  involves  comprehensive  data 
collection  procedures  and  intensive  analysis  of  these  data.  After 
demonstrating  its  usefulness  with  four  systems,  the  Army  is  Institutionalizing 
HARDMAN  into  the  acquisition  process  and  is  developing  a  guidebook  for 
standardizing  the  methodology  (ARI  and  SSC,  updated). 

MIST  (Man-Integrated  Systems  Technology)  In  a  sense  represents  a  second- 
generation  HARDMAN.  Conceptually,  it  is  similar  to  HARDMAN  but  utilizes  more 
effective  analytical  procedures  and  automated  data  handling.  It  is  antici¬ 
pated  that  MIST  will  allow  for:  (1)  reviewing  the  human  element  in  a  system 
from  both  a  performance  and  a  cost  perspective  throughout  the  system 
procurement  process;  (2)  planning  and  forecasting  of  manpower  information;  (3) 
planning  for  an  effective  training  system;  (4)  integrating  human  resource 
considerations  Into  the  test  and  evaluation  process;  and  (5)  providing  for 
overall  review  of  the  status  of  human  factors  consideration  in  the  system 
acquisition  process. 

Other  techniques  which  have  been  developed  or  are  under  development  for 
addressing  the  MPT  issue  are  the  Life  Cycle  Cost  Model  (HARDMAN  Development 
Office,  1982)  and  the  Training  Requirements  Determination  Methodology  (Pacer 
Systems,  Inc.  1982),  both  of  which  have  come  out  of  the  Navy  HARDMAN  office. 
The  Early-On  Manpower  Requirements  Estimation  Methodology  (EMREM)  (Boden, 
Hutzler,  Insley,  McNichols,  1983)  was  developed  through  the  sponsorship  of  the 
Department  of  Defense  and  attempts  to  determine  "very  early  in  the  acquisition 
process,  manpower  demand  over  the  life  cycle  of  an  individual  weapon  system." 
The  Early  Comparability  Analysis  (ECA)  (Klass,  Holzman,  and  Brandenbury,  1984) 
uses  a  variation  of  reverse  engineering  to  identify  problems  in  current 
systems  so  that  they  will  not  be  repeated  in  future  systems.  The  Army  Tank 
Automotive  Command  has  developed  a  comparability-based  system  for  estimating 
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future  system  manpower  requirements  (Army  Tank  Automotive  Command,  1982), 
(Bierly,  1984).  Other  approaches  include  the  Job  Assessment  Software  System 
(Rossmeissl,  Tillman,  Rigg,  and  Best,  1983)  and  the  Comparison  Based 
Prediction  (CBP)  methodology  (Klein  Associates,  1984),  both  of  which  attempt 
to  estimate  human  resource  requirements  for  proposed  or  new  systems. 

All  of  these  techniques  have  contributed  to  providing  MPT  estimates  early 
in  the  system  acquisition  process.  The  HARDMAN  methodology  has  been  an 

especially  useful  approach  for  both  Navy  and  Army  applications.  However, 
Improvements  to  existing  approaches  are  both  feasible  and  desirable.  While 
the  current  approaches  address  some  of  the  critical  Issues  associated  with 
providing  timely  MPT  analyses,  they  all  share,  for  the  most  part,  some  serious 
shortcomings,  both  theoretical  and  practical.  Among  the  most  serious 
shortcomings  are: 

(1)  A  focus  on  maintenance  rather  than  operator  performance, 

(2)  A  near  total  disregard  for  skill  requirements  and  soldier 
characteristics, 

(3)  An  emphasis  on  training  Issues,  and 

(4)  A  foundation  in  comparability  analysis. 

The  concept  for  Product  Five  in  part  overcomes  these  limitations.  The 
Product  Five  concept  also  makes  use  of  the  best  methods  and  procedures  already 
developed  in  HARDMAN  and  MIST. 


PRODUCT  DEVELOPMENT 


SYSTEM  APPROACH  STAGES 


Army  perse  el  make  difficult  decisions  when  developing  information  for 
evaluating  des.3n.  The  product  development  approach  provides  a  finished 
product  that  aids  personnel  In  making  those  decisions. 

The  development  process  Is  divided  Into  three  critical  stages  or  tasks: 
(1)  Concept;  (2)  Design  Specifications;  and  (3)  Production  of  Finished 
Products.  Each  stage  or  task  has  several  critical  Issues  that  are  addressed. 
As  each  task  Is  completed,  that  task's  deliverables  (concept  papers,  design 
specifications,  finished  products)  become  the  property  of  the  U.S.  Army.  At 
the  conclusion  of  each  task,  ARI  evaluates  the  resulting  concept  paper, 
detailed  design  specification  or  finished  product. 

CONCEPT  DEVELOPMENT  STAGE 


During  Task  1,  the  concept  critical  issues  were  addressed  and  specified 
above  in  the  concept  paper  objectives.  As  stated  above,  the  goal  of  this 
report  is  only  to  report  the  results  of  this  initial  concept  phase  or  task. 
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DESIGN  SPECIFICATION  STAGE 


Ouring  Task  2,  a  detailed  design  specification  of  Product  Five  that 
describes  operations,  maintenance  and  training  will  be  developed  to  establish 
the  following: 

(1)  The  required  Inputs  of  the  product,  its  location,  and  how  it  will  be 
accessed. 

(2)  The  components  of  the  product,  where  they  will  be  obtained,  and  how 
they  will  Interact. 

(3)  The  process  by  which  the  product  will  produce  its  outputs. 

(4)  The  outputs  of  the  product,  described  in  exact  man-machine  interface 
terms. 

(5)  The  means  by  which  computer  files  will  achieve  security. 

(6)  The  means  to  Insure  organizational  acceptance  of  the  outputs  of  the 
product. 

(7)  The  detailed  schedule  and  estimate  of  costs  for  product  development 
In  1986  dollars. 

The  design  specification  will  be  sufficiently  specific  that  it  will  serve  as 
the  specification  from  which  actual  product  development  proceeds. 


PRODUCTION  OF  FINISHED  PRODUCT  STAGE 

During  Phase  or  Task  3,  the  completed  product  (debugged  as  required)  will 
be  produced  and  provided.  The  product  will  be  secure  and  will  produce  the 
required  output  for  target  users.  The  product  will  include  the  following: 

(1)  All  required  operational  hardware  (either  obtained  from  the  Army  or 
purchased  as  required). 

(2)  All  required  operational  software  installed  In  the  hardware. 

(3)  All  required  data  either  loaded  into  the  hardware  or  directly 
accessible  by  the  hardware. 

(4)  All  required  training  software  installed  in  the  hardware. 

(5)  All  maintenance  documentation  for  hardware  and  software. 
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DATA  REQUIREMENTS 


PRODUCT  FIVE 

The  following  list  of  tasks  which  would  be  completely  supported  by  an 
Ideal  Product  Five  provide  the  basis  of  the  development  goals  of  the  concept 
being  proposed  for  Product  Five  Implementation: 

(1)  Define  jobs  and  the  workload  for  those  jobs. 

(2)  Recommend  MOS  for  each  duty  position. 

(3)  As  appropriate,  determine  maintenance  level  of  job. 

(4)  Determine  workload  Information  for  periods  of  heightened  operational 
tempo. 

(5)  Determine  required  capabilities  In  terms  of  content  of  tasks 

Incumbents  must  perform. 

(6)  Provide  computational  algorithm  for  determining  manpower 

requirements  as  a  function  of  cumulative  workloads;  this  algorithm 
will  be  consistent  with  those  specified  for  Army  use  (e.g.,  AR 

570-2). 

(7)  Make  provision  for  analyst  to  Iterate,  changing  inputs  and/or 

constraints,  to  achieve  convergence  on  required  quantitative 
requirements  outputs. 

(8)  Make  provision  for  a  quantitative  clustering  methodology  compatible 
with  Product  Six  -  Personnel  Characteristics  requirements. 

(9)  Provide  a  basis  for  an  early  system  design  development  decision 
regarding  the  acceptability  of  specific  design  alternatives  (against 
manpower  and  personnel  requirements). 

(10)  Assess  Impact  of  system  design  on  MPT  (quantitative)  demands. 

(11)  Translate  system  characteristics  into  MPT  demands. 

Essential  Development  Characteristics.  The  proposed  concept  has  the 
following  characteristics  as  compared  to  HARDMAN  and  MIST  (see  Figure  5): 

(a)  Oriented  toward  the  analysis  and  evaluation  of  specific  candidate 
system  designs  —  as  opposed  to  HARDMAN  and  MIST  techniques  of 
postulating  a  design  based  on  mission  and  function  analyses  and 
comparability  extrapolations. 

(b)  Oriented  towards  jobs,  rather  than  towards  MOS;  to  this  end  tasks 
will  be  aggregated  into  duty  modules,  and  duty  modules  into  duty 
positions;  a  job  engineering  capability  will  be  provided. 

(c)  More  provision  for  operator  type  performance  including  provision  for 
task  interactions;  organizational,  physical,  and  time  constraints  on 
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DESIGN  GOALS  FOR  PRODUCT  5 
AS  COMPARED  TO  HARDMAN/MIST 

•  Oriented  toward  analysis/evahation  of  specific  designs, 
not  postulated  design. 

•  Oriented  toward  jobs,  not  MOS. 

•  More  provision  for  operator  performance,  task 
interactions. 

•  Less  concern  with  training  resource  estimation. 

•  More  user  friendly. 


FIGURE  5 

Product  Five  Compared  to  HARDMAN/MIST 
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the  aggregation  of  tasks  into  jobs  will  be  scrutinized  for  both 
operator  and  maintainer  activities. 

(d)  Less  concern  with  training  issues  such  as  the  estimation  of 
Instructional  hours,  best  training  approach,  etc. 

(e)  More  user  friendly  with  better  prompting  and  aiding  and  less  demand 
placed  on  analyst's  skills  in  the  domains  of  engineering  and 
technology. 

The  proposed  concept  incorporates  the  following  approaches  to  achieve 
additional  capabilities  (see  Figure  6): 

(a)  Constraints  on  the  aggregation  of  pairs  of  job  components  (i.e., 

tasks  with  tasks,  tasks  with  clusters,  and  clusters  with  clusters) 
will  have  the  first  priority  consideration  In  the  clustering 

process. 

(b)  Commonality  of  required  competencies  (including  enabling  skills  and 
more  advanced  task  related  skills  across  tasks)  and  task  similarity 
(as  measured  by  training  transfer  potential)  will  be  considered  in 
the  aggregation  of  job  elements  into  jobs. 

(c)  Provision  for  consideration  of  MANPRINT-relevant  system  design 

features  in  the  estimation  of  workload  will  be  made. 

fd)  Provision,  as  an  option,  for  using  estimated  MOS  and  school 

boundaries  in  the  process  of  aggregating  job  elements  into  jobs  will 
be  made. 

(e)  Practical  Interfaces  with  Product  Six  will  be  provided,  to  include: 
provision  for  Identifying  tasks,  duty  modules,  and  jobs  for  use  in 
Product  Six;  provision  for  output  of  manpower  and  personnel 

quantitative  requirements  to  Product  Six;  the  provision  of  "what-if" 
capabilities  for  the  exploration  of  job  engineering  alternatives  for 
the  alleviation  of  qualitative  problems  revealed  in  the  results  of 
Product  Six. 


DATA  REQUIREMENTS  AND  SOURCES 


MAJOR  DATA  CATEGORIES 

Major  data  elements  required  for  Product  Five  can  be  grouped  into  three 
distinct  categories: 

(1)  Task  identification  and  description. 

(2)  Task  clustering  criteria  and  measurements. 

(3)  Manpower  and  personnel  management  information. 
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NEW  CONCEPTS  FOR  PRODUCT  5 


•  Constraints  as  first  priority  consideration  in 
clustering. 


•  Consideration  of  enabling  skills  commonalities  and 
training  transfer  potential  (task  similarity)  in 
aggregation  into  jobs. 


•  Consideration  of  MANPRINT-relevant  design 
features  in  workload  estimation. 


•  Optional  capability  for  consideration  of  MOS  and 
school  boundaries  in  the  aggregation  process. 


•  Outputs  for  input  to  Product  6,  Personnel 
Characteristics  Model. 


FIGURE  6 
New  Concepts 
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Significant  data  requirements  in  each  category  and  their  sources  are 
discussed  below. 


TASK  IDENTIFICATION  AND  DESCRIPTION 


The  task  and  task  data  generation  process  for  Product  Five  is  described 
In  the  "Product  Design"  Section  of  this  report.  That  section  covers  the 
process  of  task  Identification  and  generation  of  both  qualitative  and 
quantitative  descriptions  of  the  task  as  necessary  for  operation  of  Product 
Five.  In  contrast,  the  discussion  below  refers  to  the  data  which  Is  obtained 
from  external  sources  and  used  as  Input  to  the  task  generator. 

Design  Data.  Information  pertaining  to  system  design  is  expected  to  vary 
widely  In  terms  of  form,  precision,  and  completeness.  The  Product  Five  task 
generation  process  must  be  sufficiently  flexible  to  accommodate  the  data  which 
Is  available.  Types  of  design  data  which  may  be  available  for  task  generation 
are  as  follows: 

(a)  Human  Engineering  Design  Approach  Document-Operator  (HEDAD-0)  and 
Human  Engineering  Design  Approach  Document-Maintalner  (HEDAD-M).  In 
normal  acquisitions,  the  government  requires  the  contractor  to 
prepare  these  documents.  Depending  on  the  kind  of  acquisition 
process  which  the  system  being  evaluated  is  undergoing,  and  on  the 
status  of  system  development,  HEDAD-0  and  HEDAD-M  will  probably  be 
available  for  use  with  Product  Five.  The  detailed  task  descriptions 
contained  in  these  documents  can  be  used  directly  as  the  task 
identification  and  descriptions  for  Product  Five. 

(b)  Logistics  Support  Analysis  Record  (LSAR).  Again  depending  on  the 
development  status  of  the  system  design,  the  government  may  have 
required  the  contractor  to  prepare  elements  of  the  LSAR  data 
package.  These  may  have  been  among  the  deliverables  required  along 
with  basic  system  design  information.  Alternatively,  major 
positions  of  the  LSAR,  such  as  predicted  reliability  and  maintain¬ 
ability  (RAM)  values,  may  have  been  required  as  part  of  a  proposal 
for  further  system  development.  LSAR  data  contains  both  operator 
and  maintainer  tasks  and  a  preliminary  designation  of  the  Military 
Occupational  Specialty  (MOS)  and  grade  of  the  personnel  who  are  to 
perform  them.  That  Is,  like  the  HEDAD-0  and  HEDAD-M,  the  LSAR  task 
Information  is  the  product  of  extensive  task  analysis  by  the  system 
developer  for  the  proposed  design  and  should  be  used,  when 
available,  for  determination  of  job  requirements.  (Such  Information 
and  data  should  be  critically  examined  before  acceptance  for  Army 
use,  but  this  is  true  of  any  design  information  produced  by 
contractors.)  LSAR  or  maintenance  tasks  are  particularly  useful  for 
Product  Five,  in  that  each  task  Is  associated  with  specific 
components  and  quantitative  data  are  provided.  The  quantitative 
data  Includes  the  frequency  at  which  the  task  Is  expected  to  be 
required  for  both  preventive  (scheduled)  and  corrective 
(unscheduled)  maintenance  actions.  The  times  required  to  perform 
each  task  are  also  given,  in  terms  of  elapsed  time,  the  number  of 
personnel,  and  the  total  maintenance  man-hours  required  to  perform 
each  task.  The  task  frequency  and  maintenance  man-hour  information 
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are  readily  combined  to  obtain  the  total  maintenance  workloads  by 
task,  by  type  and  category  of  maintenance  action,  by  system 
component,  and  by  the  system  as  a  whole.  If  such  LSAR  data  Is 
available  It  should  be  used  for  determination  of  job  requirements. 
For  maintenance  jobs.  If  LSAR  data  Is  not  available,  then  similar 
quantitative  task  data  providing  essentially  equivalent  measures  of 
frequency  and  duration  must  be  obtained  from  other  sources  to 
compute  total  estimated  workload  and  the  consequent  number  of 
required  jobs.  One  such  source  may  be  comparable  systems  which  are 
already  fielded. 

(c)  System  Design  Descriptions.  Design  descriptions  In  the  form  of 
drawings,  narrative  descriptions,  mock-ups  or  other  relatively  early 
representations  may  be  the  only  direct  source  of  Information  on  the 
new  design.  Often  such  descriptions  can  be  used  to  Infer  the  major 
operator  tasks  associated  with  the  system,  even  If  a  detailed  task 
analysis  has  not  been  performed.  That  Is,  the  physical  system 
design  and  the  operational  characteristics  of  system  components 
often  constitute  sufficient  information  to  allow  explicit 
unambiguous  definition  of  operator  tasks,  and  even  jobs.  In  such 
instances,  operator  job  requirements  may  be  established  without 
further  task  clustering  analyses. 

General,  non-quantltatlve  system  design  descriptions  are  usually  In 
themselves  Inadequate  for  the  determination  of  maintenance  job  requirements. 
Since  maintenance  jobs  are  a  function  of  the  maintenance  workload  Imposed  by 
all  components  of  a  system,  some  estimated  measure  of  maintenance  task 
frequencies  and  corresponding  task  durations  —  maintenance  manhours  —  must 
be  available  to  determine  the  number  of  jobs  and  people  demanded  by  the 
system.  Measured  data,  appropriately  adjusted,  can  be  obtained  from 
comparable  fielded  systems  for  which  such  data  are  available. 

For  both  the  determination  of  operator  data  and  jobs,  and  the  selection 
of  comparable  systems  for  maintenance  workload  estimates,  a  degree  of  subject 
matter  expertise  is  required.  If  the  Product  Five  analyst  does  not  possess 
that  expertise  in  the  system  being  analyzed,  then  assistance  from  qualified 
Subject  Matter  Experts  (SMEs)  will  be  needed. 

COMPARABLE  SYSTEMS  DATA 

If  quantitative  workload  data  for  the  development  system  has  not  been 
developed  in  the  form  of  an  LSAR  or  a  similar  RAM  data  base,  then  it  must  be 
estimated,  task  by  task.  In  order  to  determine  maintenance  job  requirements. 
This  estimate  can  be  made  using  data  from  comparable  systems  for  which  data  is 
available.  Subject  matter  expertise  will  be  needed  in  most  instances  in  order 
to  choose  appropriately  comparable  systems.  Comparability  may  be  required  in 
terms  of  mission,  function,  performance  characteristics,  and/or  technology. 
Expertise  is  also  necessary  to  extrapolate  the  maintenance  workload  from  the 
measured  values  for  comparable  systems  to  estimated  values  for  the  new  system. 
The  extrapolation  is  based  primarily  on  the  estimated  changes  between  old  and 
new  systems  in  terms  of  performance  characteristics  and  technology.  Changes 
in  basic  system  function  allocations  must  also  be  considered. 
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Data  on  comparable  existing  systems  can  be  obtained  from  such  sources  as 
LSAR  and  the  Sample  Data  Collection  (SDC)  program;  data  acquisition  can 
usually  be  arranged  through  the  cognizant  project  manager's  office. 

Comparable  system  data  will  be  useful  primarily  for  estimation  of  new 
systems  maintenance  workload  and  for  subsequent  maintenance  job  analysis. 
Although  some  insights  into  operator  task  analysis  may  be  provided  by 
comparable  existing  systems,  operator  task  information  in  most  applications 
will  be  derived  primarily  from  direct  analysis  of  the  proposed  new  system 
design.  As  required.  Subject  Matter  Experts  will  be  needed  to  supplement  the 
basic  Product  Five  analyst. 


TASK  CLUSTERING  CRITERIA  AMD  MEASURES 

Jobs  are  defined  by  Product  Five  as  clusters  of  the  tasks  necessary  for 
operation  and  maintenance  of  a  system.  The  process  for  clustering  the  system 
tasks  is  governed  by  two  general  criteria.  First,  the  clustering  must  conform 
to  rigidly  imposed  sets  of  constraints;  and  second,  the  clusters  which  are 
formed  must  be  better,  by  a  quantitative,  objective  measure,  than  other 
permissible  clustering  patterns  which  are  not  chosen.  The  constraints,  in 
turn,  are  of  two  general  types.  First,  before  any  clustering  activities  take 
place,  the  provisions  of  a  clustering-permissibility  matrix  are  imposed.  The 
permissibility  matrix  establishes  whether  each  possible  pairwise  combination 
of  system  tasks  is  permitted  or  not.  (In  depicting  the  two-dimensional 
matrix,  a  "0"  at  the  intersection  of  two  tasks  indicates  they  may  not  be 
placed  in  the  same  cluster,  while  a  "1"  indicates  that  such  a  clustering  is 
permitted  but  not  required.  Hence,  the  matrix  is  often  referred  to  in  this 
report  as  the  "0/1"  matrix.)  There  is  no  provision  in  the  permissibility 
matrix  requiring  any  pairs  of  tasks  to  be  clustered  together;  if  such 
associations  are  considered  mandatory,  they  are  effected  by  combining  them 
into  a  larger  task  —  a  required  cluster  —  before  inputting  them  into  Product 
Five.  Also,  note  that  impermissibility  is  absolute.  A  zero  in  the 
permissibility  matrix  means  that  the  indicated  pair  tasks  cannot  be  in  the 
same  cluster  no  matter  how  many  other  tasks  they  might  both  be  permitted  to 
cluster  with. 

The  second  type  of  constraint  employs  certain  threshold  values  to  limit  the 
extent  of  clustering  of  otherwise  permissible  pairings.  That  is,  the  number 
of  tasks  combined  into  a  single  job  may  be  limited  by  threshold  value 
limitations  on  the  total  workload  involved,  the  multiplicity  of  required 
compentencles,  or  the  degree  of  overall  technical  complexity  which  arises  from 
task  combinations.  The  paragraphs  which  follow  discuss  the  data  requirements 
and  sources  for  the  clustering  process. 

Task  Interrelationships  and  Initial  Constraints.  The  clustering 
permissibility  matrix  governing  initial  clustering  constraints  is  developed  by 
examination  and  analysis  of  tasks  to  ascertain  which  pairs  of  theirs  cannot  be 
placed  in  the  same  task  cluster.  Information  for  making  these  determinations 
is  obtained  through  a  task  analysis  conducted  by  the  Product  Five  analyst 
and/or  supporting  SME's.  Reasons  for  establishing  Impermissibility  could 
include  the  fo1 lowing: 
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(1)  Time  and  space  relationships.  When  two  distinct  tasks  must  be 
conducted  simultaneously  and  both  require  the  full  efforts  of  the 
performing  Individual,  then  obviously  they  cannot  be  assigned  to  the 
same  job  (same  person).  Similarly,  two  tasks  which  must  be 
performed  at  nearly  the  same  time  but  at  relatively  separated 
locations  cannot  be  a  part  of  the  same  job. 

(2)  System  design  and  function  allocation.  The  assignment  of  tasks  to  a 
particular  job  Is  often  an  obvious.  Inherent  function  of  system 
design.  Placement  of  controls  and  system  monitoring  components  at 
the  work  station  of  an  Individual  clearly  Intended  to  perform 
certain  tasks  amounts  to  a  de  facto  clustering  of  those  tasks  Into  a 
particular  job.  This  may  be  reflected  by  the  Product  Five  analyst 
and/or  SME  as  a  larger,  predetermined  task  cluster,  and  Input  into 
the  permissibility  matrix. 

(3)  Clear  divergence  of  technological  domains.  Tasks  may  be  so 
different  In  their  technological  makeup  that  allowing  the  clustering 
algorithm  to  Investigate  their  Inclusion  In  the  same  job  would  be  an 
obvious  waste  of  time  and  effort.  In  employing  this  rationale, 
however,  the  analyst  must  take  care  not  to  accept  blindly  a 
"traditional''  way  of  looking  at  these  Issues  at  the  expense  of  an 
objective  analysis. 

(4)  Army  policy.  In  a  number  of  developmental  systems,  policy  decisions 
regarding  the  number  of  certain  jobs  have  been  promulgated  by  the 
Army  for  Incorporation  In  the  designs,  e.g.,  number  of  tank  crewmen, 
number  of  helicopter  pilots. 

Initial  clustering  constraints  via  the  permissibility  matrix  are 
considered  far  more  likely  to  be  applied  to  operator  tasks  and  jobs  than  to 
maintainers.  In  many  Instances,  operator  job  decisions  will  be  possible  even 
without  Identifying  and  describing  the  Individual  tasks  involved.  In  these 
Instances,  the  task  analysis  for  generating  input  to  Product  Five  would  in 
part  be  required  only  for  Input  Into  Product  Six.  (This  assumes  that  a  single 
task  Identification  and  description  process  can  support  both  Products  Five  and 
Six,  and  that  both  products  will  be  developed.)  Some  maintenance  tasks  may 
also  be  subject  to  clustering  permissibility  contraints,  particularly  con¬ 
straints  due  to  technological  divergence. 

Clustering  Measures:  Competencies.  The  primary  objective  function 

governing  task  clustering  uses  a  measure  designated  as  the  Simularity  and 
Utility  (S/U)  measure.  This  measure  is  derived  from  training  parameters.  The 
intuitive  rationale  for  clustering  a  task  with  a  given  task  or  set  of  tasks, 
as  opposed  to  all  the  others  it  could  be  clustered  with,  is  some  concept  of 
similarity.  Otherwise  random  clustering  of  any  set  of  tasks  not  expressly 
prohibited  from  clustering  would  be  as  efficient  and  effective  as  a  more 
careful  approach.  The  measure  of  similarity  chosen  for  Product  Five  is 
commonality  of  "competencies". 

As  stated  above,  the  concept  of  competencies  is  an  S/U  measure.  Briefly, 
competencies  are  the  basic  skills  and  capabilities  which  the  operator  or 
malntalner  must  possess  to  enable  him  to  perform  the  higher  order,  more 
complexly  structured  system  tasks.  Examples  of  competencies  are  ability  to 
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use  a  torque  wrench,  a  multimeter,  or  complex  electronic  fault  Isolation 
equipment,  or  proficiency  on  a  standard  typewriter  and  computer  keyboard. 

It  Is  possible  for  a  constituent  competency  for  a  relatively  complex  task 
to  be.  In  Itself,  a  stand-alone  task  In  a  given  context.  A  key  characteristic 
of  a  competency  as  used  In  the  S/U  measure  is  that  it  be  taught  in  Army 
Programs  of  Instructions,  and  that  It  Is  now  or  could  potentially  be  common  to 
more  than  one  task. 

The  source  for  competency  data  Is  the  Army  training  system,  specifically, 
TRADOC  schools.  Insofar  as  basic  enabling  skills  are  already  documented  for 
Programs  of  Instruction,  existing  data  In  systems  and  tasks  comparable  to  the 
new  system  can  be  employed  by  the  Product  Five  analyst  in  ascertaining  the 
competencies  required  for  new  system  tasks.  In  the  case  of  tasks  for  which 
comparable  lists  of  competencies  are  not  available,  subject  matter  expertise 
must  be  employed  to  determine  appropriate  competencies.  In  many  Instances, 
the  Product  Five  analyst  will  be  capable  of  making  such  determinations  without 
outside  assistance,  particularly  If  baseline  system  data  files  are  available 
for  reference.  The  architecure  of  Product  Five  will  include  the  baseline 
files,  but  the  cost  of  developing  comprehensive  competencies  cross-referenced 
to  a  wide  variety  of  existing  systems  will  probably  prevent  their  preparation 
as  part  of  the  Product  Five  development  effort.  Alternatively,  the  baseline 
reference  jobs  will  be  built  in  conjunction  with  successive  Product  Five 
applications. 

Subject  matter  experts  from  the  training  community  will  be  needed  on  a 
more  frequent  basis  for  determining  competency  training  times.  These  training 
times  are  the  basis  for  the  Similarity  and  Utility  measure  which  drives  the 
clustering  algorithm.  Commonality  of  competencies  among  tasks  causes  a 
measurable  decrease  in  the  total  training  effort  when  those  tasks  are  combined 
in  a  single  job  performed  by  the  same  individual,  compared  to  training  more 
than  one  person  in  the  common  competencies.  The  training  time  saved  is  a 
useful  measure  of  the  relative  value  of  clustering  choices,  and  if  used  would 
in  fact  cause  a  reduction  in  training  times  and  costs.  More  importantly, 
however,  the  training-based  Slmularity  and  Utility  measure  was  chosen  because 
it  is  believed  to  express  better  than  any  other  measurable  factor  the  basic 
rationale  for  assembling  system  tasks  into  jobs. 

The  reference  competency  file  to  be  included  in  Product  Five  will,  when 
completed  in  successive  applications,  contain  descriptors  for  accessing 
competencies.  These  descriptors,  which  include  a  school  domain  category, 
school  and  course  title  applicable  to  the  competency,  and  a  technology 
category,  will  be  derived  by  the  Product  Five  analyst  from  information 
obtained  from  Army  schools.  Training  SME's  will  be  required  to  assist  the 
analyst. 

Baseline  Systems  Information.  Competencies  required  for  a  major  portion 
of  new  system  tasks  will  be  determined  through  analysis  of  the  tasks  by  the 
Product  Five  analyst,  with  assistance  from  system  and  training  Subject  Matter 
Experts.  Determination  of  competencies  for  other  tasks  will  be  facilitated  by 
reference  to  existing  systems,  tasks,  and  associated  training  courses. 
Therefore,  provision  will  be  made  in  Product  Five  for  a  Baseline  System 
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reference  file  whlc..  will  contain  lists  of  competencies  for  selected  existing 
systems.  If  funding  levels  permit,  the  constraints  of  the  baseline  file  will 
be  developed  as  part  of  the  total  Product  Five  development. 

Descriptions  In  the  Baseline  Systems  File  are  similar  to  those  In  the 
competency  file.  They  include  the  baseline  system  name,  the  school  domain 
categories  for  each  set  of  baseline  tasks,  school  and  course  titles  which 
provide  training  in  the  baseline  tasks,  and  the  task  technology  category. 

Information  for  the  Baseline  System  File  will  be  obtained  from  Army 
schools  in  the  form  of  Programs  of  Instructions,  Lesson  Plans  and  other 
available  course  documentation.  Training  and  baseline  system  subject  matter 
experts  will  be  required  when  system  competencies  are  not  explicitly 
associated  with  the  tasks.  Task  data  itself  is  available  in  the  published 
training  documents. 

Technology  Complexity  Information.  The  Product  Five  analyst  will  be 
provided  the  option  of  considering  overall  job  complexity  levels  in  the 
process  of  clustering  tasks  into  duty  modules  and  jobs.  A  provision  will  be 
made  in  the  clustering  algorithm  to  limit  the  total  complexity  score  of  a  job 
by  setting  maximum  threshold  values.  Job  complexity  scores  are  the  sum  of 
complexity  scores  of  the  individual  constituent  tasks.  Task  complexity  scores 
will  be  determined  by  the  Product  Five  analyst.  A  decision  aid  will  be 
provided  in  the  product  to  assist  the  analyst;  even  with  the  decision  aid, 
system  SME  assistance  will  be  needed  by  the  analyst,  unless  he  possesses 
system  expertise  himself.  (Similarly,  training  SME's  and  SME's  of  represen¬ 
tative  Army  systems  will  provide  input  on  the  design  of  the  decision  aid,  as 
part  of  the  overall  Product  Five  development.) 

MANPOWER  AND  PERSONNEL  MANAGEMENT  INFORMATION 

For  Manpower  and  Personnel  in  Product  Five,  a  determination  of  the 
manpower  and  personnel  impacts  of  the  job  organization  is  implicit  in  the 
estimation  of  the  number  of  jobs  and  the  description  of  those  jobs  in  terms  of 
their  constituent  tasks.  In  fact,  for  maintenance  functions,  workloads  and 
associated  measuring  criteria  specified  by  the  Army  are  the  basis  for 
determining  the  number  of  required  jobs.  Also,  Product  Five  will  provide  an 
option  whereby  the  current  MOS  and  school  structure  of  the  Army  can  influence 
the  task  clustering  process. 

To  obtain  data  for  manpower  and  personnel  management,  manpower  work 
capabilities  have  to  be  determined.  Basic  manpower  requirements  at  various 
maintenance  levels  (e.g.,  organizational ,  direct  support,  general  support)  are 
determined  by  comparing  the  workload  demands  for  a  given  job  type  with  the 
available  working  hours  of  the  maintainers.  In  current  practice,  workload  and 
working  hour  availabilities  are  managed  in  terms  of  Military  Occupational 
Speciality,  but  Product  Five  will  not  be  restricted  by  those  boundaries. 
Nevertheless,  a  comparison  of  required  workload  in  terms  of  manhours  and  the 
Annual  Available  Maintenance  Manhours  (AAMMH)  for  various  types  of  maintainers 
will  continue  to  be  the  basis  for  determining  the  number  of  maintenance  jobs 
required. 
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Required  maintenance  workloads  are  determined  In  Product  Five  by  summing 
the  workloads  for  each  maintenance  task  included  In  a  job  cluster.  Main¬ 
tenance  work  availability  data  are  obtained  from  Army  Regulations  570-E, 
Manpower  Requirements  Criteria  (MARC).  MARC  data  is  presented  In  terms  of 
MOS.  For  most  applications  of  Product  Five,  when  MOS  boundaries  are  not 
considered  binding,  the  Product  Five  analyst  will  be  required  to  select  the 
most  suitable  values  and  computational  rules  from  the  regulation,  based  on  the 
general  category  of  maintenance  action  to  be  performed  and  on  the  type  of 
equipment  involved.  SME  assistance  will  be  required  only  rarely.  If  at  all. 

School  and  MOS  Boundaries.  Product  Five  will  be  designed  to  allow  the 
analyst  to  give  explicit  considerations  to  the  current  MOS  structure  as  he 
controls  the  task  clustering  and  job  formation  process.  When  the  option  to 
consider  MOS  Is  Involved,  a  "preferred"  MOS  will  be  assigned  to  each  task, 
based  on  the  MOS  which  perform  comparable  tasks  on  existing  systems.  The 
analyst  will  also  establish  penalty  values  for  clustering  tasks  with  different 
"preferred"  MOS.  When  an  Input  total  threshold  penalty  value  Is  reached  for  a 
given  cluster,  further  clustering  across  MOS  boundaries  cannot  occur.  Since 
the  clustering  algorithm  selects  the  "best"  clustering  decisions  at  each 
iterative  step  of  the  process,  the  MOS  boundary  threshold  prohibits  the 
clustering  of  relatively  less  similar  tasks,  in  an  objective  similarity  sense, 
while  allowing  clusters  of  those  which  are  relatively  more  similar. 

Information  to  assist  the  analyst  In  assigning  "preferred"  MOS  to  tasks 
can  be  obtained  from  a  number  of  sources.  Army  Regulation  611-201  provides  a 
detailed  description  of  each  MOS.  Task  data  for  comparable  systems,  found, 
for  example,  in  Logistics  Support  Analysis  Records  (LSAR)  can  also  provide 
input,  as  can  information  from  existing  programs  of  Instruction  (POI)  for 
candidate  MOS.  In  some  instances,  input  from  either  system  or  training  SME's 
may  be  useful,  but  such  requirements  should  be  minimal. 

Penalty  values  for  crossing  MOS  boundaries  and  maximum  threshold  values 
for  prohibition  of  additional  cross-boundary  clustering  will  be  established  by 
the  analyst.  Product  Five  documentation  will  provide  guidelines  for 
establishing  the  values,  but  when  the  MOS  boundary  option  is  employed,  the 
analyst  must  choose  values  which  meet  his  particular  analytical  needs. 

Personnel  Rates.  Existing  methodologies  such  as  HARDMAN  and  MIST  (Man 
Integrated  Systems  Technology)  are  used  to  determine  the  number  of  jobs,  or 
manpower  spaces,  for  new  systems.  Similar  information  will  be  generated  by 
Product  Five.  Specifically,  the  number  of  personnel  which  the  Army  must 
maintain  in  the  inventory  in  order  to  fill  the  required  manpower  spaces  will 
be  estimated,  along  with  the  corresponding  annual  personnel  inputs  accessions, 
reclassifications)  necessary  to  sustain  the  required  inventory. 

Rates  with  which  to  make  personnel  estimates  are  readily  available.  The 
U.S.  Army  Military  Personnel  Center  (MILPERCEN)  regularly  publishes  the 
DAPC-238  report  containing  historical  -  MOS  Trainee,  Transient,  Holdees  and 
Student  (TTHS)  rates.  These  can  be  used  to  translate  manpower  (spaces) 
requirements  into  requirements  for  personnel  (faces).  Both  MILPERCEN  and  the 
Defense  Manpower  Data  Center  (DMDC)  have  personnel  flow  rates,  such  as  losses 
and  promotions,  which  can  be  used  to  determine  the  requirements  for  annual 
personnel  input  to  sustain  the  required  inventory. 
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CLASSES  OF  INFORMATION 


ARCHITECTUAL  DESIGN 


Modules  and  Module  Components.  The  modules  of  the  proposed  concept 
Implementation  are  depicted  In  Figure  7.  These  modules  can  be  loosely  defined 
In  terms  of  the  decision  aids  and  models  utilized,  the  data  bank  files 
accessed  and  the  working  files  created  or  accessed.  The  decision  aids  and 
models  will  be  embedded  In  a  common  software  environment.  This  environment 
and  the  aids  and  models  together  will  be  referred  to  as  a  model  bank.  The 
model  bank,  the  data  bank,  the  working  files,  and  user  interface  software  will 
comprise  the  computer  aided  components  of  the  concept  Implementation  of 
Product  Five. 

The  term  data  bank  will  be  used  In  this  report  to  refer  to  the  set  of 
Information  files  created  during  product  development  for  the  purpose  of 
residing  permanently  In  the  product  and  which  are  supported  by  user  friendly 
retrieval  software  (embedded  in  decision  aids)  and  is  utilized  in  a  decision 
making  and  working  file  generation  In  conjunction  with  one  or  more  decision 
aids.  Some  data  bank  files  will  have  provision  for  having  additional  records 
added  by  the  analyst.  Working  files  created  entirely  by  analysts  may  also  be 
retained  and  optionally  accessed  at  a  later  date,  but  such  files  are  not 
considered  to  be  part  of  the  data  bank. 

The  Data  Bank  and  Working  Files.  Whereas  the  data  bank  files  will  be 
Integral  to  the  product,  exlstfng  prior  to  the  first  use  of  the  product  by  an 
analyst,  the  working  files  come  into  existence  as  a  result  of  the  analysts 
efforts  with  respect  to  a  specific  new  system  under  MANPRINT  evaluation.  The 
working  files  provide  the  means  of  passing  information  across  modules,  to  the 
analyst,  and  finally  to  Product  Six.  Thus,  the  working  files  provide  the 
thread  that  ties  the  modules,  and  their  decision  models  and  aids  Into  a  single 
Integrated  product. 

The  task  description  file  Is  comparable  to  a  undlrectional  data  bus;  each 
module,  commencing  with  task  Identification  and  continuing  through  manpower 
and  personnel  requirements,  uses  and  adds  to  the  task  records  of  this  file. 
The  job  component  (cluster)  file  may  have  many  trial  versions  but  will  have  a 
continuing  existence  In  some  form  from  Its  creation  during  duty  module 
generation  on  to  the  point  where  final  output  files  are  prepared.  Some 
working  files  will  be  accessed  only  within  the  module  where  they  were 
Initially  produced.  Such  local  files  have  the  function  of  organizing  and 
recording  (documenting)  the  analysts  efforts  in  creating  other  files  which  do 
cut  across  module  or  product  boundaries. 

The  data  base  will  contain  four  distinct  files.  The  one  of  greatest 
Importance  will  be  referred  to  as  the  "competency  file".  This  file  Is  the 
source  of  Information  on  the  utility  resulting  from  two  tasks  having  various 
degrees  of  commonality  of  competencies. 

Competencies  Include  enabling  skills,  such  as  use  of  a  torque  wrench  or 
multimeter,  but  also  Include  more  advanced  skills  and  knowledge  that  can  be 
expected  to  be  required  by  a  number  of  tasks  that  are  similar  --  in  that  they 
share  a  requirement  that  the  Incumbent  have  this  more  advanced  competency.  An 
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FIGURE  7 

Product  Five  Design 
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example  of  such  a  more  advanced  competency  is  provided  by  the  knowledge  of 
triangulation  methods  necessary  for  two  different  operators'  tasks  --  one  in 
which  the  height  of  nearby  trees  must  be  accurately  estimated  —  and  another 
task  In  which  the  distance  to  a  known  location  must  be  estimated.  Each 
competency  record  has  several  descriptors,  the  compentency  title  (phrase),  and 
the  value  of  not  having  to  train  a  soldier  in  this  competency  (time  to  train 
and  maintain).  This  data  base  content  must  be  collected,  largely  from  Army 
school  doctrine  and  experience,  as  part  of  the  Phase  3  product  development 
process. 

The  second  data  base  file  will  be  referred  to  as  the  "uaseline  systems 
file".  This  file  will  have  the  same  three  descriptors  as  the  "competency 
file".  These  descriptions  fall  Into  three  categories:  1)  a  coded  technology 
category,  (2)  a  coded  school  domain  category,  3)  system  and  subsystem 
category,  and  mission  type.  Each  record  will  have  a  baseline  system  title, 
proponent  of  system  operation  (for  the  baseline  system  relevant  to  the 
operator),  and  proponent  of  system  maintenance  (for  the  baseline  system 
relevant  to  the  malntalner),  and  Identification  of  relevant  soldier's  manuals, 
In  addition  to  the  descriptors.  The  Information  for  this  file  is  obtainable 
from  school  POI  and  other  course  documentation  and/or  from  the  proponent 
school's  Combat  Development  (CD)  organization. 

The  third  data  base  file  will  be  referred  to  as  the  "MOS  and  School 
Boundaries  File".  That  file  will  Include  the  description  and  much  of  the 
Information  contained  In  the  other  data  bank  files  structured  In  such  a  way  as 
to  permit  the  exploration  of  MOS  and  School  Boundaries  with  respect  to  each 
task. 


The  Model  Bank:  Decision  Models  and  Aids.  The  models  and  decision  aids, 
with  associated  data  bank  or  working  flle(s)  are  organized  by  the  modules 
depicted  in  Figure  1  and  7  and  listed  in  Figure  8.  These  models  and  decision 
aids  will  be  separately  considered  in  section  titled  "Module  Logic  and 
Processes".  Our  concern  here  will  be  with  the  overall  process  and  the  flow  of 
Information  and  results  from  the  first  to  the  last  of  the  modules. 

The  distinction  In  this  report  between  the  desigratlon  of  decision  aiding 
software  as  decision  models,  as  contrasted  with  being  referred  to  simply  as 
decision  aids.  Is  based  on  the  presence  of  significantly  more  Information 
analysis  algorithms  in  the  models  as  compared  to  decision  aids.  Those 
designated  as  models  also  contain  several  submodels  and  decision  aids,  and 
provide  the  analyst  with  recommended  solutions  --  as  contrasted  with  the 
support  of  the  analysts  own  organizing,  recording  and  decision  process 
provided  by  those  designated  as  decision  aids.  All  working  files  are 
supported  by  a  decision  aid,  but  sometimes  (e.g.,  with  respect  to  the 
"constraint  categories  file"),  a  working  file  Is  essentially  a  scratch  pad  and 
a  provider  of  documentation  for  a  decision  aid. 

There  are  four  decision  models  in  the  concept  design  proposed  in  this 
report  for  specification  and  Implementation  In  phases  2  and  3.  These  models 
are  as  follows: 
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Product  Five  Models  &  Decision  Aids 

(Figure  8 ) 
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Product  Five  Models  &  Decision  Aids 

(Figure  8  Continued) 


Short  Description  of 
Model/Aid 
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(See  Fig.  1) 
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Aggregation  Model 
(See  Figures  11  &  12). 
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Workload  Model:  Aids, 
prompts,  computing  aids, 
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load  data. 
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Product  5 
Output 
File 


(1)  Aggregation  Model, 

(2)  Workload  Model, 

(3)  MOS  and  School  Boundaries  Model, 

(4)  Manpower  and  Personnel  Requirements  Model. 

USER  AND  SYSTEM  INTERACTIONS 

Menu  of  Models  and  Decision  Aids.  The  analyst  can  call  up  a  menu  of 
decision  aids  and  models  at  any  point  In  his  analysis.  He  can  use  anything  on 
the  menu  provided  the  working  file  required  as  input  Is  at  an  adequate  stage 
of  preparation,  or  he  Is  willing  to  provide  the  data  and  create  the  required 
working  file.  This  permits  the  analyst  to  perform  what-lf  analyses  with 

hypothetical  data  if  he  so  desires. 

The  Sequence  of  Events.  The  analyst  Is  in  complete  control  of  the 
sequence  of  events  while  using  Product  Five.  To  that  end  he  must  start  each 
model  and  decision  aid;  there  will  be  no  automatic  communication  across 
decision  aids  and  models.  All  communications  across  decision  aids  and  models 
occur  through  the  use  of  working  files  that  are  subject  to  review  and 
modification  by  the  analyst.  Some  decision  aids  have  the  primary  function  of 
creating  or  adding  to  working  files  while  others  may  use  one  working  file 
created  elsewhere  as  input  and  create  another  working  file  as  an  output.  The 
Product  Five  software  shell  will  assure  that  the  appropriate  working  files  are 
used  as  input  and/or  output  by  each  decision  aid  and  model  across,  as  well  as 
within  modules. 

The  Alternative  Sequences.  If  the  analyst  has  alternative  sources  for 
task  sets  and  task  descriptions,  and  does  not  want  to  first  generate  duty 
modules  he  may  follow  the  following  sequence  of  modules  (from  figure  1): 

(1)  Task  Identification 

(2)  Task  Data  Generation 

(3)  Workload  Data  Generation 

(4)  Duty  Position  Generation 

(5)  Manpower  and  Personnel  Requirements 

The  more  usual  sequence,  with  less  information  about  tasks  at  the 
beginning  and  a  need  to  more  carefully  define  jobs,  involves  the  following 
module  sequence: 

(1)  Baseline  System  Identification 

(2)  Baseline  Systems 

(3)  Task  Identification 

(4)  Task  Data  Generation 

(5)  Duty  Module  Generation 

(6)  Workload  Data  Generation 

(7)  Determination  of  MOS  and  School  Boundaries 

(8)  Duty  Position  Generation 

(9)  Manpower  Personnel  Requirements 

The  analyst  may  review  the  results  from  step  9  and  reset  clustering 
criteria  in  order  to  iterate  through  steps  5  through  9  again. 
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MODULE  LOGIC  AND  INTERNAL  PROCESS 


Task  Identification  and  Task  Data  Generation.  The  basic  relationship 
between  the  design  of  a  new  system  and  the  jobs  and  people  to  operate  and 
maintain  It  is  defined  by  the  human  tasks  involved.  Product  Five  formulates 
jobs,  and  determines  the  required  number  of  them,  by  clustering  the  human 
tasks  In  a  rational,  systematic  manner.  System  operation  and  maintenance  must 
therefore  be  defined  and  described  in  such  a  way  as  to  allow  the  clustering 
algorithm  to  operate.  Basic  task  definition  and  description  requirements  are 
given  below: 

.  Task  name. 

.  Task  type,  operator  or  malntainer. 

.  Word  description.  In  sufficient  detail  to  enable  understanding 
of  what  must  be  done  with  each  subsystem  or  component  of  the 
system.  This  description  must  support  analysis  for 

determination  of  the  competencies  associated  with  the  task. 

.  Information  describing  the  relationship  of  the  task  to  other 
tasks.  Primary  relationships  will  be  in  terms  of  time  and/or 
distance.  Such  relationships  will  be  significantly  more 

important  for  operator  tasks  than  for  maintainer  tasks. 

.  Quantitative  Information  on  maintenance  task  frequencies  and 
durations.  This  data  Is  necessary  for  the  computation  of 
maintenance  workloads,  which  In  turn  are  used  to  determine  the 
required  number  of  maintenance  jobs. 

Sources  of  task  data  are  discussed  In  detail  In  "Data  Sources." 
Essentially,  task  data  are  derived  both  from  analysis  of  available  design 
information  for  the  new  system  and  from  data  available  for  comparable  existing 
systems.  Descriptions  and  data  for  both  operator  and  maintainer  tasks  will  be 
derived  from  new  system  design  Information,  but  this  design  Information  is  of 
overriding  importance  for  operator  tasks.  Unless  there  has  been  extensive 
maintenance  task  analysis,  as  reflected  in  the  Logistics  Support  Analysis 
Record  (LSAR)  or  similar  Reliability  and  Maintainability  data,  a  primary 
source  for  qualitative  and  quantitative  maintenance  task  descriptions  will  be 
existing  systems  which  are  comparable  to  the  new  developmental  system.  If  a 
Human  Engineering  Design  Approach  Document  -  Operation  (HEDAD-0)  and/or  a 
Human  Engineering  Design  Approach  Document  -  Maintenance  (HEDAD-M)  are 
available,  they  will  constitute  a  prime  source  of  task  data. 

Methods  for  generating  task  data  will  depend  on  the  degree  to  which 
specific  design  data  Is  available,  and  the  extent  to  which  these  data  reflects 
any  previous  task  analyses  by  the  system  developer.  If  extensive  task 
analysis  have  been  performed,  to  include  task  sequence  analyses  for  operators 
and  frequency  and  duration  determinations  for  maintainers,  then  essentially  no 
additional  task  generation  will  be  required  for  Product  Five.  More  likely, 
only  incomplete  task  Information  will  be  available  to  the  analyst.  In  that 
case,  all  available  design  information  (including  drawings,  narrative  system 
descriptions,  function  allocations,  and  performance  characteristics)  will  be 
used  to  generate  system  tasks. 
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When  operator  task  analysis  results  are  unavailable,  task  Information 
must  be  generated  from  other  sources.  The  primary  source  will  be  new  system 
design  information  augmented  as  necessary  by  task  data  on  existing  comparable 
systems.  Task  descriptions  will  be  derived  by  examining  the  operation  of  the 
new  system  In  detail  and  drawing  logical  inferences  regarding  the  function  of 
the  human  component  of  the  system.  For  example,  the  design  of  a  target 
acquisition  device  will  essentially  define  the  actions  which  the  operator  must 
take  to  use  it,  as  will  the  design  of  a  vehicle's  steering,  braking,  and  speed 
control  systems.  Examination  of  the  design  of  the  various  components  of  a 
crew-served  system  and  their  functional  interactions  during  operation  will 
define  the  required  crew  tasks  and  their  sequence.  In  instances  where  the 
design  is  unclear,  comparable  system  tasks  can  be  used  to  assist  and  augment 
the  analysis  of  new  system  tasks. 

The  determination  of  operator  task  Information  which  Is  otherwise 
unavailable  will  be  accomplished  by  the  analyst  who  is  applying  Product  Five. 
In  the  likely  event  that  he  is  not  expert  in  the  design  of  systems  similar  to 
the  new  system,  assistance  from  SME's  will  be  required. 

Identifying  and  describing  maintenance  tasks  for  a  new  system  require  a 
process  which  is  significantly  different  from  that  for  operator  tasks.  While 
basic  system  design  information  allows  determination  of  operator  tasks,  and 
often  direct  determination  of  operator  jobs,  maintenance  information  can 
seldom  be  directly  derived.  Unless  one  is  thoroughly  expert  In  the  tech¬ 
nology,  there  Is  virtually  no  way  to  ascertain  the  reliability  and  maintain¬ 
ability  of  complex  systems  by  examining  the  plans  for  their  design.  The 
direct  identification  and  qualitative  description  of  maintenance  tasks  would 
itself  be  a  formidable  effort,  but  quantitative  descriptions  would  be 
essentially  Impossible. 

To  overcome  the  difficulties  of  direct  maintenance  tasks  analysis,  the 
Product  Five  analyst  will  utilize  task  data  from  comparable  systems.  The 
functions,  performance  characteristics,  and  technology  of  the  new  system  will 
be  analyzed  and  matched  as  closely  as  possible  by  systems,  subsystems,  and 
components  of  existing  systems  for  which  maintenance  data  Is  available.  The 
data  will  then  be  extrapolated  judgmentally  to  reflect  as  accurately  as 
possible  the  difference  between  the  existing  and  new  systems.  The  resulting 
quantitative  and  qualitative  task  descriptions  are  used  in  the  Product  Five 
task  clustering  and  job  definition  process. 

Interpretation  of  possibly  Incomplete  system  design  Information, 
Identification  of  comparable  systems,  and  extrapolation  of  quantitative  and 
qualification  task  data  from  existing  to  future  systems  requires  an 
appreciable  measure  of  system  expertise.  If  the  Product  Five  analyst  is  not 
reasonably  expert  in  the  type  of  system  being  analyzed,  the  assistance  of  a 
system  Subject  Matter  Expert  will  be  required. 

Aggregation  of  Job  Components.  The  provision  of  an  overriding  priority 
to  the  eligibility  of  job  components  for  combination  with  other  components  in 
the  making  of  task  aggregation  decisions  was  considered  to  be  essential.  It 
Is  further  desirable  that  these  eligibility  considerations  be  made  explicit  to 
the  analyst  with  a  clear  option  for  the  lifting  of  each  separate  constraint  on 
eligibility  made  available  at  appropriate  decision  points. 
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Since  further  aggregation  decisions,  within  the  restrictions  imposed  by 
the  eligibility  considerations,  will  be  made  on  the  basis  of  a  Similarity  and 
Utility  (S/U)  measure,  it  Is  desirable  that  the  variables  determining 
eligibility  and  the  variables  contributing  to  the  S/U  measure  be  logically 
Independent.  Most  of  the  eligibility  considerations  differ  from  those 
contributing  to  the  S/U  measure  in  that  they  are  readily  expressed  as  binary 
variables.  After  compulsory  aggregations  of  job  components  are  implemented, 
the  relationships  among  the  remaining  components  can  be  expressed  In  a 
zero/one  matrix  where  a  one  Indicates  that  aggregation  Is  permitted  and  a  0 
Indicates  that  aggregation  of  that  pair  Is  prohibited.  However,  other 
variables  relevant  to  the  clustering  process  that  less  clearly  take  on  the 
values  of  must,  must  not,  or  permissiveness  may  still  be  placed  in  the 
constraint  variable  (eligibility)  category  If  they  also  do  not  readily  take  on 
a  value  along  a  continuum  of  utility  variable  values.  Those  variables  which 
make  an  Independent  contribution  to  the  clustering  decision,  but  do  not  have  a 
logically  clear  relationship  to  the  S/U  variable,  must  be  considered  in  the 
context  of  the  constraint  matrix. 

The  eligibility  conditions  expressed  in  the  constraint  matrix  should 
reflect  what  experts  consider  to  be  mandatory  rules  when  they  undertake  a 
process  of  defining  duty  modules  or  jobs  from  tasks.  These  eligibility 
variables  should  also  reflect  supervisory  decision  criteria  used  to  group 
tasks  for  assignment  to  Individual  subordinates. 

The  Role  of  the  Constraint  Matrix.  Tasks  will  have  been  coded  (within 
the  Task  Data  Generation  Module)  with  respect  to  characteristics  that  indicate 
strong  indications  for  either  combining  or  not  combining  pairs  of  tasks,  or 
conversely,  indicate  the  permissability  of  combining  a  given  pair  of  tasks. 
Criteria  for  making  this  determination  are  summarized  in  Figure  9. 
Inseparable  tasks  are  immediately  aggregated  into  task  clusters  making  it 
possible  to  represent  in  a  constraint  matrix  all  pairwise  eligibility 
determinations  among  job  components  (task,  or  task  clusters)  as  a  0 
(prohibited)  or  a  1  (permissable) . 

Whenever  a  pair  of  job  components  (either  tasks,  task  clusters,  or  task 
and  cluster)  is  aggregated  to  form  a  single  component  the  order  of  the 
constraint  matrix  is  reduced  by  one.  The  boolean  "and"  operation  on  the  two 
constraint  vectors  being  merged  into  one  provides  the  new  0/1  row  and  column 
vector  representing  the  new  combined  job  component.  All  other  vectors  in  the 
matrix  remain  the  same. 

The  degree  of  connectivity  found  in  the  constraint  matrix  may  be  so  high 
as  to  leave  most  of  the  clustering  decisions  to  considerations  of  the  S/U 
measure.  Most  maintainer  activities  may  fall  in  this  category.  Conversely, 
many  operator  activities  may  yield  a  constraint  matrix  of  such  low 
connectivity  that  no  flexibility  for  further  clustering  with  the  S/U  measure 
remains.  Thus,  an  immediate  feedback  of  the  maximum  and  minimum  number  of 
clusters  permitted  by  a  constraint  matrix  will  then  provide  the  analyst  the 
option  of  proceeding  to  the  workload  determination  module  and  then  returning 
to  the  Duty  Position  Generation  Module  to  accomplish  all  further  clustering 
decisions  using  the  0/1  constraint  matrix  and  the  workload  aggregation  matrix. 
The  alternative  to  this  option  Is  to  proceed  to  the  aggregation  step  that 
utilizes  the  S/U  measure. 
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CLUSTERING  CRITERIA 


AGGREGATION  ELIGIBILITY 

•  Task  Interactions/Relationships 

—  Simultaneity 

—  Appropriately  Time  Shared 

—  Prerequisite  Relationships 

—  Inseparable  Tasks  Form  A  Single  Job  Component 

•  Organizational/Supervisory  Structure 

—  Analyst  must  define  and  code  categories 

--  As  controlled  by  analyst,  clustering  prevented  across  organizational  lines. 

•  Physical  Constraints  --  Location,  Barriers 

--  Analyst  defines/codes  each  task  for  separated  work  areas. 

--  Aggregation  of  separated  tasks  prevented. 

•  System/Technology  Category 

--  "Doctrine"  on  inseparability  of  responsibility  for  system/subsystem 
components. 

—  "Doctrine"  on  inseparability  of  mission/function  components  relating 
to  tactical  objectives. 

--  Inseparable  tasks  Form  A  single  job  component. 


FIGURE  9 
Clustering  Criteria 
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The  analyst  has  the  additional  options  (in  addition  to  those  offered  by 
the  setting  of  constraints  to  form  the  0/1  matrix)  of  prohibiting  aggregation 
that  exceed  threshold  values  set  by  the  analyst  for  the  following  variables: 

(1)  Workload  Sum  for  Each  Cluster 

(2)  Technology  and  Training  Complexity 

(3)  Extent  MOS  and  School  Boundaries  Are  Violated 

Each  of  the  above  three  constraint  variables  can  be  computed  and 
considered  each  time  a  pair  of  job  components  Is  selected  as  yielding  the 
maximum  value  for  the  S/U  measure.  If  the  aggregation  of  a  pair  is  prohibited 
because  a  threshold  value  set  by  the  analyst  is  exceeded,  the  1  is  changed  to 
a  0  In  a  working  copy  of  the  0/1  constraint  matrix,  the  aggregation  Is  not 
accomplished,  and  the  pairwise  hunt  for  the  maximum  value  of  the  S/U  value  for 
eligible  pairs  continued. 

These  three  constraint  variables  are  of  Interest  to  the  analyst  for  the 
following  reasons: 

(a)  The  workload  sum  for  each  cluster  must  be  below  a  specified  number 
In  order  for  it  to  be  considered  as  a  job  for  one  soldier. 

(b)  The  technology  and  training  complexity  value  (essentially  a  by 

product  of  the  computational  process  that  yields  a  value  for  a  S/U 
measure)  should  not  be  too  high  because  of  implications  for 

personnel  qualitative  requirements. 

(c)  The  extent  MOS  and  School  boundaries  are  violated  should  not  exceed 

an  amount  that  the  analyst  believes  can  be  tolerated  without 

disruption  of  either  the  personnel  or  training  system. 

The  S/U  Measure.  An  Ideal  S/U  measure  would  incorporate  all  the  factors 
an  expert  considers  in  the  allocation  of  tasks  to  jobs  In  the  construction  of 
a  TOE  (or  a  TDA),  In  the  defining  of  a  new  MOS,  in  the  determination  of 
requirements  during  a  manpower  survey,  or  In  a  hypothetical  situation  in  which 
a  job  engineering  process  of  rearranging  duty  modules  within  a  set  of  jobs  to 
Increase  efficiency  is  being  undertaken.  Such  an  ideal  S/U  measure.  If 
maximized  In  a  clustering  process,  should  agree  with  the  decisions  a  true 
expert  would  make  if  he  had  the  mission  and  time  to  conduct  a  careful 
consideration  of  all  system  tasks  and  to  cluster  them  into  jobs.  Actually, 
the  S/U  measure  used  in  this  product  is  utilized  to  make  decisions  within  the 
space  remaining  after  the  0/1  constraints  have  been  applied,  and  also  need  not 
duplicate  the  measurement  domains  of  the  three  additional  criterion  variables 
for  which  threshold  values  may  be  (optionally)  assigned.  Thus,  the  factors 
the  S/U  measn^e  should  cover  are  considerably  reduced.  In  summary,  the  ideal 
S/U  measure  should  reflect  what  experts  would  consider,  above  and  beyond  the 
Implications  of:  (1)  the  0/1  constraints,  (2)  technological  complexity,  (3) 
school  and  MOS  boundaries,  and  (4)  workload  distribution. 

An  Ideal  S/U  measure  would  also  reflect  supervisory  decision  criteria  in 
grouping  tasks  for  assignment  to  individual  subordinates.  Again,  our  S/U 
measure  should  be  relatively  orthogonal  to  the  variables  included  as 
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constraints  to  form  the  0/1  matrix  or  used  as  threshold  criteria  in  deter¬ 
mining  whether  a  selected  merger  will  be  allowed  to  stand,  while  incorporating 
the  remaining  variables  considered  by  the  supervisor. 

The  major  considerations  not  already  covered  by  the  constraint  or 
criterion  variables  cited  above  would  most  likely  include  the  need  to  maximize 
the  probability  that  an  incumbent  can  be  selected  who  can  perform 
satisfactorily  on  all  tasks  assigned  to  him,  and  to  maximize  the  reduction  of 
training  effort  and  cost.  There  Is  a  definite  utility  in  the  selection  of  two 
tasks  for  merger  Into  a  job  (for  an  individual)  when  the  probability  Is  high 
that  an  Individual  who  can  do  one  task  well  can  also  do  the  other  well. 
Similarly  there  is  a  high  utility  for  merging  a  task  into  an  existing  cluster 
of  tasks  when  the  task  to  be  added  brings  no  new  competencies  to  be  learned  by 
the  Incumbent. 

To  be  acceptable  the  S/U  measure  must  clearly  comprise  an  objectively 
determined  utility  function.  It  must  have  an  easily  understood  metric  on 
which  to  measure  similarity  of  tasks  in  terms  of  a  scale  that  is  directly 
proportional  to  the  Increase  or  decrease  of  utility.  The  metric  should  be  at 
least  an  interval  scale  with  some  of  the  features  of  a  ratio  scale  (with  a 
true  zero).  An  ordinal  scale  is  definitely  not  acceptable.  It  must  be 
possible  to  measure  the  relative  utility  of  adding  a  job  component  to  each  of 
the  other  components  and  to  identify  the  pairing  which  would  provide  the 
greatest  utility,  and  to  compare  the  utility  of  that  optimal  merger  to  the 
utility  that  would  result  from  leaving  the  two  job  components  unmerged  (as 
candidate  duty  modules  or  jobs).  The  above  criteria  for  selecting  a  S/U 
variable  are  summarized  in  Figure  10, 

It  is  essential  that  a  S/U  measure  not  require  unreasonable  demands  on 
the  analyst  in  terms  of  either  his  ability  to  make  judgments  or  of  his  time. 
Thus,  while  the  analyst  Is  required  to  make  decisions  and  to  provide  coded 
Input  at  the  task  level,  he  is  not  required  to  make  judgments  on  task  pairs 
(or  worse  yet  on  task  sets  of  3,  of  4,  etc.). 

The  algorithm  appropriate  for  computing  an  S/U  value  associated  with  a 
possible  merger  of  two  job  components  is  dependent  on  the  nature  of  the  S/U 
measure.  Thus  it  Is  essential  to  choose  a  S/U  measure  that  will  permit  an 
economical  comparison  of  all  candidate  mergers--with  the  additional 
calculation  of  S/U  values  at  each  iterative  step  kept  at  a  minimum.  The  S/U 
measure  must  be  meaningful,  and  fully  comparable  across  job  components 
containing  widely  different  numbers  of  constituant  tasks,  in  order  to  permit 
an  iterative  algorithm  based  on  making  pairwise  comparisons. 

The  S/U  measure  must  have  a  clear  relationship  to  an  underlying  measure 
of  utility  to  the  Army.  To  this  end,  the  S/U  measure  must  not  involve  the 
combination  of  two  or  more  variables,  unless  all  the  variables  are  expressed 
In  a  common  metric  (such  as  dollars,  training  time,  predicted  standard 
performance,  etc.)  that  will  be  retained  in  the  combination  process.  The  use 
of  arbitrary  weighting  of  such  diverse  variables  as  workload,  technological 
complexity  or  functional  similarity  to  form  a  utility  function  is  especially 
to  be  avoided. 
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CLUSTERING  CRITERIA 


DEFINITION  OF  THE  S/U  VARIABLE  GOALS 


•  Reflect  experts'  criteria  in  defining  duty  modules,  jobs. 

•  Reflect  supervisors’  criteria  in  grouping  tasks  for  subordinates 

•  Clearly  compromise  an  objectivity  defined  utility  function. 

•  Credible  similarity,  utility  scale 

•  A  direct  relationship  between  the  similarity  between  two  tasks 
and  utility  to  the  Army. 

--  Probability  that  if  soldier  can  accoplish  one  task  he  can 
accomplish  the  other. 

--  A  reduction  in  the  training  effort  and  cost  for  one  task  if  he  is 
proficient  in  the  other. 


FIGURE  10 

Definition  of  the  S/U  Variable 
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As  stated  above,  it  is  highly  desirable  that  the  scale  on 
which  the  s/u  measure  is  expressed  provide  for  at  least  internal 
scale  relationship.  The  scale  should  have  the  capability  of 
meaningfully  expressing  a  difference  between  the  utility  of  two 
alternative  mergers  in  terms  of  the  increments  resulting  from  a 
merger  as  compared  with  the  utility  of  leaving  each  merger 
candidate  unpaired  —  even  when  one  alternative  pairing  is  at  the 
high  end  of  the  s/u  scale  and  the  other  alternative  is  at  the  low 
end.  The  one  yielding  the  largest  increase  in  s/u  value 
resulting  from  the  merger  will  be  selected.  The  use  of  this  kind 
of  algorithm  obviously  requires  a  highly  sophisticated  scale. 
The  provision  of  only  an  ordinal  scale  in  the  s/u  measure  would 
require  the  use  of  a  different  algorithm  for  selecting  an 
"optimal"  pair  of  job  components  for  aggregation. 

The  s/u  measure  used  for  Product  Five  will  be  considered  at 
three  levels  of  sophistication.  At  all  three  levels  the  s/u 
measure  is  expressed  in  terms  of  the  hours  required  to  train  an 
incumbent  to  perform  the  job  component.  The  s/u  measure 
increment  is  the  gain  in  reduced  training  time  resulting  from  a 
merger  of  two  components  as  compared  to  the  training  time 
required  if  both  components  were  kept  separate  and  assigned  to 
different  incumbents.  That  increment  is  made  to  be  positive  by 
multiplying  a  negative  difference  by  (-1);  it  is  then  maximized 
by  selecting  the  pair  of  job  components  that  yields  the  greatest 
gain.  Each  successive  merger  also  maximizes  the  gain  that  is 
obtainable  at  that  iteration.  Since  the  order  of  the  s/u  value 
matrix  and  the  0/1  constraint  matrix  are  both  reduced  by  one 
during  each  iteration,  the  process,  if  not  stopped  for  another 
reason  (e.g.,  because  no  more  eligible  pairings  exist)  would 
eventually  reach  the  point  where  only  two  job  components  remain 
to  be  compared.  The  variables  defining  the  s/u  measure  at  Level 
1  remains  the  most  important  consideration  at  Levels  2  and  3. 
Similarly,  the  Level  3  variables  are  added  to  the  Level  1  and  2 
variables  for  the  more  sophisticated  Level  3  concept.  The 
variables  to  be  introduced  at  each  development  level  are 
summarized  in  Figure  11  and  Table  1. 

The  competencies  required  for  the  accomplishment  of  a  task  are 
identified  by  the  analyst  during  the  Task  Data  Generation  Module. 
Candidate  competencies  corresponding  to  descriptors  input  by  the 
analyst  are  retrieved  from  the  data  base.  When  a  list  of 
competencies  have  been  selected  for  a  task,  additional 
information  is  drawn  from  the  data  base,  including  initial 
training  time  and  training  maintenance  time  associated  with  each 
competency.  Competencies  consist  of  both  enabling  skills  and 
more  advanced  task  related  skills  that  cut  across  two  or  more 
tasks.  Generic  tasks  described  so  generally  that  tasks  within  a 
family  of  such  tasks  could  be  defined  by  adding  more  specificity 
can  also  be  named  as  competencies.  The  time  required  to 
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CLUSTERING  CRITERIA 


DEFINITION  OF  THE  S/U  VARIABLE 
SELECTED  S/U  MEASURE 


Function  of: 

•  Commonality  of  competencies  (Level  1 ) 

•  Similarity  of  tasks  in  terms  of  amount  of  training  transfer 
(Level  2) 

•  Learning  decay  rate  (Level  3)  Importance  of  each  competency 
to  achievement  of  task  objectives  (Level  3) 

•  Frequency  of  task  performance  (Level  3) 

Metric: 

•  Expressed  in  terms  of  training  hours  for: 

--  Initial  training 
--  Training  maintenance 


FIGURE  11 

Selected  S/U  Measure 
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TABLE  1 


COMPARISON  OF  THE  S/U  MEASURE  ACROSS 
DEVELOPMENTAL  LEVELS 


DEVELOPMENTAL 

LEVEL 

SUMMARY  OF  SAJ  MEASURE 

VARIABLES 

CONTRIBUTING 

TO  S/U  MEASURE 

1 

INITIAL  TRAINING  HOURS  TO 

PROVIDE  COMPETENCE 

REQUIRED  BY  TASKS 

COMPETENCE 

2 

DEVELOPMENTAL  LEVEL  ONE 

S/U  MEASURE  ••WEIGHTED 

BY  IMPORTANCE  TO  THE  ACHIEVEMENT 
OF  TASK  STANDARDS-  MINUS 

TRAINING  TRANSFER  EFFECTS 

COMPETENCE 

TRAINING  TRANSFER 

IMPORTANCE  WEIGHTING 

3 

DEVELOPMENTAL  LEVEL  TWO 

S/U  MEASURE  PLUS 

TRAINING  HOURS  CONTRIBUTING  TO 
TRAINING  MAINTENANCE 

COMPETENCE 

TRAINING  TRANSFER 

IMPORTANCE  WEIGHTING 

LEARNING  DECAY  RATE 

PERFORMANCE  FREQUENCY 
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train  the  more  advanced  competencies  will  be  based  on  assumptions  that 
competence  In  all  prerequisite  enabling  skills  is  present. 

The  S/U  value  for  a  job  component  is  the  sum  of  the  training  hours 
associated  with  each  competency  required  by  that  job  component  (a  task  or  a 
cluster  of  tasks).  When  two  job  components  are  merged  their  competency  sets 
are  combined  Into  a  common  set  and  duplicates  removed.  The  S/U  value  for  the 
new  job  component  resulting  from  the  merger  (aggregation)  Is  again  the  sum  of 
the  training  hours  associated  with  each  competency  required  by  that  job 
component. 

The  S/U  value  for  a  candidate  merger  of  every  pair  of  job  components  will 
be  computed  initially  and  again  for  each  new  row  added  to  the  S/U  value 
matrix.  A  new  row  will  be  added  each  time  two  rows,  corresponding  to  two 
components  being  aggregated,  are  deleted  and  the  new  merged  job  component 
added  to  the  matrix.  Thus,  only  one  row  of  S/U  values  need  be  computed  at 
each  iteration  in  which  a  merger  is  effected. 

The  selection  of  the  "best"  pair  of  job  components  for  merger  during  a 
given  iteration  will  be  made  on  the  basis  of  a  difference  defined  as  the 
training  hours  of  one  job  component  plus  the  training  hours  of  the  other  job 
component  minus  the  training  hours  of  the  merged  job  component.  When 
multiplied  by  (-1)  this  difference  becomes  the  gain  Increment  which  is 
maximized  at  each  Iteration  of  the  aggregation  process. 

Functional  Definition  at  Developmental  Level  2  permits  the  consideration 
of:  (1)  the  Importance  of  each  competency  to  the  accomplishment  of  task 
standards,  and  (2)  the  use  of  generic  tasks  in  terms  of  training  transfer 
effects  rather  than  as  required  competencies.  The  Product  Five  developmental 
cost  would  Increase  very  little  if  it  Is  decided  to  advance  to  level  2, 
however  both  level  2  features  require  additional  analyst  judgments  and  his 
time  to  input  this  Information  during  the  Task  Data  Generation  Module. 

The  Importance  of  each  competency  to  the  accomplishment  of  task  standards 
would  be  used  as  weights  for  computing  the  weighted  sum  of  training  hours  each 
time  a  S/U  value  Is  computed  by  the  product.  This  feature  would  Increase  the 
face  validity  of  the  S/U  measure  by  making  this  measure  more  directly  related 
to  task  and  system  performance. 

To  Incorporate  Into  the  S/U  measure  the  training  transfer  effects  that 
similar  tasks  provide  for  each  other,  the  analyst  would  define  one  or  more 
generic  tasks  that  reflect  the  perceived  similarity  relevant  to  training 
transfer  across  a  number  of  tasks.  Each  generic  task  would  be  compared  with 
similar  competencies  of  the  data  bank  and  a  training  hours  value  accordingly 
assigned  to  the  generic  task.  The  analyst  then  estimates  the  training 
transfer  commonality  of  each  generic  task  with  each  relevant  task.  The  impact 
of  the  training  transfer  effect  of  a  generic  task  on  each  system  task  must  be 
considered  In  a  different  manner  than  Is  the  Impact  of  a  requirement  (as  a 
prerequisite)  for  a  competency.  The  requirement  for  a  competency  Is 
additional  to  the  specific  training  required  to  accomplish  a  task,  whereas  the 
training  transfer  effect  provides  for  the  deletion  of  a  portion  of  the  task 
specific  training.  Since  task  specific  training  is  a  constant  across  two  job 
components  before  and  after  merger  (If  training  transfer  is  not  being 
considered),  the  required  task  specific  training  does  not  need  to  be 
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considered  in  level  1  or  level  2  definitions  of  the  S/U  measure.  Thus,  in  the 
levels  1  and  2  concepts  of  the  S/U  measure,  it  was  essential  that  anything 
contributing  to  training  hours  be  entered  only  once  for  each  job  component. 
This  contrasts  with  the  logical  need  to  subtract  the  training  transfer  effect 
from  the  task  specific  training  for  each  task.  Moreover  the  amount  that 
should  be  subtracted  from  each  task  Increases  more  tasks  similar  to  the 
generic  task  are  Included  In  a  cluster  —  with  the  increment  for  adding 
another  relevant  task  becoming  less  and  less  until  an  asymptote  Is  reached. 
The  formula  for  reflecting  this  desired  relationship  (of  training  transfer 
effect  to  the  measure  of  required  training  hours  utilized  by  the  S/U  measure) 
will  be  discussed  further  In  the  discussion  section. 

Functional  Definition  at  Developmental  Level  3.  Developmental  level  3 
permit!  the  consideration  of:  (1)  learning  decay  rate  and,  (2)  frequency  with 
which  each  task  will  be  performed.  Training  maintenance  cost  Is  more  when 
learning  decay  rate  is  high  and  less  as  frequency  of  task  performance 
Increases.  The  primary  developmental  cost  Is  In  the  addition  of  an  estimated 
learning  decay  rate  to  each  competency  record  In  the  data  bank.  The  manner  In 
which  decay  rate  would  be  estimated  will  be  covered  in  the  discussion  section. 
The  frequency  estimate  will  be  provided  by  the  analyst  during  the  task  data 
generation  module. 

In  level  3  estimates  of  the  S/U  measure,  the  hours  of  training  main¬ 
tenance  associated  jointly  with  a  task  and  a  competency  will  be  a  function  of 
the  required  frequency  of  training  and  the  training  time  required  of  trainer 
and  trainee  to  conduct  a  relevant  on-the-job  training  session  for  the  honing 
of  that  competency.  The  required  frequency  of  training  is  In  turn  a  function 
of  learning  decay  rate  and  frequency  with  which  competency  is  exercised  across 
all  tasks  included  in  a  job  component.  With  sufficient  performance  frequency 
the  required  frequency  of  training  goes  to  zero.  As  the  learning  decay  rate 
is  Increased  the  amount  of  required  performance  frequency  which  will  reduce 
the  required  frequency  of  training  to  zero  goes  up. 

A  General  Description  of  the  Algorithm  for  Optimizing  the  S/U  Gain.  The 
S/U  measure  will  be  initially  computed  for  each  task  and  placed  in  a  task-by¬ 
task  matrix.  These  Individual  tasks  constitute  the  Initial  set  of  job 
components  that  will  be  considered  for  aggregation.  This  aggregation  process 
includes  the  trial  merger  of  a  pair  of  job  components  yielding  the  highest  S/U 
measure  increment  at  each  iteration  and  the  testing  (optionally)  against  the 
three  constraint  criteria  relating  to  a  minimum  S/U  measure  Increment,  a 
maximum  permissable  technology  complexity  and  the  extent  school  and  MOS 
boundaries  are  violated.  If  the  trial  merger  passes  all  criterion  tests 
stipulated  by  the  analyst,  the  aggregation  will  be  effected,  the  rows  and 
columns  representing  the  two  components  deleted  from  both  the  S/U  measure  and 
constraint  matrices,  and  a  new  row  and  column  added  to  represent  the  new 
(merged)  job  component.  Thus  the  order  of  both  matrices  are  reduced  by  one  at 
the  end  of  each  Iteration.  The  next  iteration  is  proceeded  by  testing  with 
respect  to  the  stopping  rules.  That  is,  does  any  pair  of  job  component 
candidates  for  further  aggregation  that  meets  all  prescribed  criteria  remain. 

The  variables  contributing  to  the  S/U  measure  in  each  of  the  three 
developmental  levels  are  summarized  in  Table  1.  The  computations  required  for 
each  level  I  Iteration  to  produce  a  S/U  measure  value  falls  into  two  steps, 
first  the  removal  of  all  duplicate  competencies,  and  secondly,  the  summing  of 
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all  initial  training  hours  associated  with  each  competency.  The  S/U  measure 
obtained  for  two  job  components  whose  competency  sets  have  been  concatenated 
(aggregated  with  duplicates  removed)  is  then  subtracted  from  the  sum  of  the 
S/U  values  computed  separately  for  those  two  job  components.  When  multiplied 
by  (-1)  this  Is  the  S/U  gain  increment  that  would  be  obtained  from  the 
candidate  merger.  These  gain  values  are  retained  in  a  S/U  increment  matrix  so 
as  to  preclude  having  to  compute  theca  gain  values  for  more  than  one  row  per 
iteration. 

Level  2  computations  to  obtain  a  S/U  value  include  the  same  treatment  of 
competencies  as  for  level  1,  except  that  training  hours  associated  with  a 
competency  are  weighted  by  an  Importance  weight  that  is  unique  to  a  pairing  of 
a  task  and  a  competency.  Also,  the  training  transfer  effects  associated  with 
a  task  are  subtracted  from  the  weighted  (by  Importance)  sum  of  training  hours 
attached  to  the  competencies  required  by  the  task.  The  S/U  gain  Is  computed 
in  the  same  manner  as  in  level  1. 

The  level  3  version  of  the  S/U  measure  uses  the  same  computational 
process  as  levels  1  and  2  with  the  additional  consideration  of  another 
variable  (frequency  of  task  performance)  In  conjunction  with  an  altered 
procedure  for  arriving  at  training  maintenance  hours.  The  number  of  training 
hours  required  for  training  maintenance  is  computed  as  a  function  of:  (1) 
training  decay  rate  for  the  task  and,  (2)  frequency  of  performance  of  the 
task,  (3)  the  importance  weight— and  added  to  the  S/U  measure  as  it  would  be 
computed  for  level  2.  The  S/U  gain  is  computed  as  in  levels  1  and  2. 

The  Overall  Aggregation  Process.  The  overall  algorithm  for  successively 
optimizing  the  S/U  gain  or  increment  includes  rules  for:  (1)  identifying 
eligible  pairs,  (2)  computing  the  S/U  gain,  (3)  selecting  the  best  pair,  (4) 
testing  against  additional  criteria  for  evaluating  the  benefits  from  a 
proposed  merger,  (5)  effecting  the  merger,  and  (6)  determining  whether  the 
aggregation  process  is  finished  or  another  iteration  should  be  commenced. 
This  process  is  depicted  in  Figure  12. 

Several  routes  through  the  aggregation  process  are  available  depending  on 
which  options  have  been  turned  on  by  the  analyst.  One  route,  with  selected 
options  turned  on  and  two  options  depicted  as  being  available  to  the  analyst, 
is  shown  in  greater  detail  for  the  selected  options  as  Figure  13. 


PRODUCT  DESIGN 

THE  INFORMATION  AND  AIDS  OF  THE  PRODUCT 


Data  Base  (DB)  Information.  Information  content,  apart  from  the 
provision  of  a  process  and  analytic  aids  for  the  Implementation  of  that 
process,  is  provided  by  four  data  bank  files.  The  information  provided  in 
those  data  bank  fi ies  can  be  directly  accessed  by  the  analyst  and  are 
available  to  be  used,  with  the  aid  of  the  data  bank  shell,  whether  or  not 
other  parts  of  Product  Five  are  also  utilized. 

The  content  and  structure  of  these  four  data  bank  files  are  described 
above.  These  files  are  summarized  in  Table  2. 
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*  Represents  a  pass  through  when  option  is  turned  off,  or  a  yes  when  option  is  turned  on. 

*  *  Largest  cluster  (M)  has  number  of  tasks  less  than  or  equal  to  N  1  (Ms_N  1 )  on  first  iteration, 

on  suceeding  iterations  branch  if  M  is  equal  to  order  of  matrix. 

*  *  *  Largest  cluster  (M)  has  number  of  tasks  less  than  N2and  greater  than  N1(N1<M<N2). 


FIGURE  12 

Overall  Aggregation  Process 
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SCHEMATIC  FOR  AGGREGATION  OF  JOB  COMPONENTS 


FIGURE  13 

Aggregation  of  Lab  Components 
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Table  2 


The  Four  Data  Bank  Files 


File  Name 

Content  of  Each  Record 

Descriptors 

Competency 

File 

At  Developmental  Levels 

1  and  2 

School  Domain  Category 

.  Competency  Short  Title 
.  Competency  Long  Title 
.  Initial  Required 

Training  Hours 
.  Short  Description  of 
Competency  (Possibly  In 
a  Separate  File  Using 
Competency  Short  Title 
as  the  Descriptor) 

.  School  and  Course  Title 
.  System/Subsystem  Category 

.  Technology  Category 

.  Mission  Category 

.  MOS 

Additional  for  Developmental 
Level  3 

.  Required  Frequency  of 

Training  Maintenance 
(Learning  Decay  Rate) 
for  Each  Competency 

(A  Descriptor  Menu  will 
be  Provided  user  by  shell  — 
logical  "and"  or  logical 
"or"  can  be  used  with 
multiple  descriptors.) 

Baseline 

Systems 

File 

.  Name  of  Systems/ 

Subsystems  Currently 

In  Inventory 
.  Associated  MOS(s) 

.  Associated  School (s) 

.  Descriptors  Linked 
to  Record 

.  Name  of  Candidate  Baseline 
System 

.  Otherwise  same  as  for 
competency  file;  the 
analyst  can  obtain 
candidate  descriptors  for 
use  In  accessing  competency 
file. 

MOS  and 
School 
Boundaries 
File 

.  Same  as  for  Baseline 

Systems  File 

.  Task  data  recorded  on  task 
data  file  will  be  used  as 
descriptors.  May  include 
competencies,  D/Cs,  and 

descriptors  used  by  analyst 
in  accessing  other  DB  files. 
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Decision  Aids  for  the  Use  of  DB  Files.  In  addition  to  the  shell,  which 
permits  the  analyst  to  access  each  DB  File,  Product  Five  provides  a  decision 
aid  to  assist  the  analyst  In  accessing  the  Competency  File,  and  the  Baseline 
Systems  File.  These  decision  aids  will  assist  the  analyst  in  making  any 
required  judgments  and  will  assist  him  In  recording  information  extracted  from 
the  DB  Files  directly  onto  other  working  files,  including  the  Task  Data 
Working  File  that  provides  input  for  both  the  Aggregation  Model  and  the  School 
and  MOS  Boundaries  Model.  The  School  and  MOS  Boundary  File  Is  automatically 
accessed  by  the  School  and  MOS  Boundaries  Model,  using  the  Task  Data  Working 
File  to  obtain  the  descriptors,  when  the  analyst  selects  the  option  of  testing 
selected  pairs  against  a  specified  minimum  boundary  violation  score.  The 
analyst  can  also  directly  access  this  latter  file  through  the  data  bank  shell. 

Decision  Aids  for  the  Generation  of  Task  Data.  Several  specialized 
decision  aids  for  prompting  and  guiding  analysts  In  the  generation  of  task 
data  will  be  provided.  The  decision  aid  for  Identifying  and  assigning  scores 
to  generic  tasks  will  use  a  special  working  file  on  which  to  record  candidates 
for  further  consideration  and  additional  judgments  prior  to  later  transfer  to 
the  Task  Data  Working  File.  The  decision  aid  for  assisting  the  analyst  in 
using  the  competency  file  will  also  write  candidate  competencies  on  a  working 
file  for  his  review  before  the  later  transfer  of  selected  competencies  to  the 
Task  Data  Working  File.  Other  decision  aids  with  a  greater  scope,  such  as 
those  discussed  below,  will  also  provide  for  recording  the  results  on  a 
working  file— either  the  Task  Data  Working  File  or  the  Product  5  Output  File. 

Decision  Aids  for  Taking  an  Analyst  Through  an  Analytic  Process.  Other 
decision  aids  will  guide  and  assist  the  analyst  through  an  analytic  process 
that  Includes  information  gathering,  decision  making,  recording  of  partial 
results,  reviewing  of  results  and  the  recording  of  final  results  for  output  to 
either  a  working  file  or  the  Product  Five  Output  File.  One  decision  aid. 
Incorporated  In  the  Product  executive,  covers  the  total  process  and  Indicates 
when  the  analyst  should  make  use  of  each  of  the  other  models  and  decision 
aids.  The  workload  data  generation  decision  aid  covers  a  process  that 
Includes  the  use  of  the  workload  model.  Similarly  the  Manpower  and  Personnel 
Requirements  Decision  Aid  Includes  Instructions  for  using  the  Manpower 
Requirements  Model. 

Product  Five  Models.  The  provision  of  relatively  complex  analyses  using 
automatic  Input  from  the  Task  Data  Working  File,  as  well  as  the  usp  of 
parameter  and  criterion  (threshold)  values  provided  by  the  analyst,  is 
provided  by  the  four  models.  Except  for  the  Manpower  and  Personnel 
Requirements  Model,  which  outputs  to  the  Product  Five  Output  File,  all  models 
automatically  output  to  the  Task  Data  Working  File  (duty  modules  and  jobs  are 
defined  In  an  appendage  to  this  file). 

Of  the  four  models,  the  computations  performed  are  the  most  complex  for 
the  aggregation  module.  However,  the  Identification  and  counting  of  the  links 
between  descriptors  and  school  domains  (as  Is  accomplished  In  the  School  and 
MOS  Boundary  Model)  could  for  some  task  sets  confront  an  analyst,  attempting 
to  perform  these  steps  manually  with  an  even  more  difficult  and  confusing 
process.  The  other  two  models,  the  Workload  Model  and  the  Manpower  Require¬ 
ments  Model,  could  conceivably  be  programmed  on  a  progranmiable  hand  calculator 
possessing  a  moderately  large  memory,  provided  the  analyst  was  experienced  and 
competent  or  guided  by  a  decision  aid  of  the  type  provided  by 
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Product  Five.  It  makes  more  sense,  of  course,  to  place  these  two  models 
within  the  same  overall  software  shell  as  contains  the  other  two  Product  Five 
models. 

The  Information  Needs  of  the  Analyst.  System  Implementations  to  be 
processed  through  Product  5  will  come  to  the  analyst  with  varying  amounts  of 
Information  regarding  the  design  features  and  operational  doctrine  of  the 
system.  The  Information  will  not  only  come  with  varying  degrees  of 
completeness  but  will  arrive  In  varying  formats  and  with  Information  gaps 
occurring  for  different  parts  of  the  system.  The  analyst  must  not  only 
perform  as  a  transducer  to  convert  the  available  Information  into  the  content 
and  format  required  by  Product  Five,  but  must  creatively  gather  additional 
Information  that  did  not  arrive  In  the  packet  sent  to  the  analyst  from  higher 
headquarters  (or  from  a  sponsor).  The  Product  Five  decision  aids  can  prompt 
the  analyst  as  to  what  Is  needed  but  the  analyst  remains  the  transducer. 

Similarly,  the  Information  on  baseline  systems  to  be  utilized  In  workload 
data  generation  must  be  obtained  by  the  analyst.  It  would  not  be  economical 
to  build  a  data  base  containing  such  perishable  Information  over  such  an 
extensive  domain.  It  Is  most  practicable  for  the  analyst  to  obtain  this 
Information  as  it  Is  needed,  just  as  is  true  of  MIST. 

In  general,  the  Information  needed  by  the  analyst,  but  not  provided  by 
one  of  the  four  data  bases  of  Product  Five,  Is  Information  that  the  analyst 
would  also  have  to  obtain  in  much  the  same  way  If  he  were  using  MIST  or  other 
available  methodologies. 

Information  Provided  by  Product  Five.  The  analyst  may  access  the  data 
base  files  to  obtain  estimates  of  training  costs  and/or  technological 
complexity  for  tasks  relating  to  proposed  design  changes,  or  for  tasks  judged 
to  be  high  driver  tasks  based  on  information  from  other  products  or  from  other 
prior  analyses.  Other  Intermediate  outputs,  such  as  the  technical  complexity 
of  jobs  containing  specific  tasks  or  the  number  of  viable  duty  positions 
required,  may  be  utilized  to  answer  specific  questions  posed  from  higher 
headquarters  or  sponsors. 

In  addition  to  the  final  output  file  provided  by  Product  Five,  the 
analyst  may  conduct  "what-lf"  analyses  in  which  the  estimated  Impact  of  design 
changes  In  the  developmental  system  being  analyzed  is  assessed.  Similarly 
additional  Iterations  could  be  executed  with  changed  Product  Five  aggregation 
criteria  and  constraints  If  Product  Six  results  indicate  unsatisfactory 
qualitative  demands. 

The  final  output  file  will  be  provided  in  two  formats,  one  In  the  precise 
format  that  Product  Six  requires  for  an  Input  file,  and  secondly  In  a  format 
that  provides  maximum  readability  and  understanding  for  the  use  of  the 
analyst.  The  analyst  will  review  this  second  file  before  determining  that  the 
first  file  Is  ready  to  be  provided  as  Product  Six  Input. 

The  Information  output  from  Product  Five  will  Include  jobs  and  duty 
modules  In  terms  of  the  constituent  tasks;  the  number  of  each  job  required  for 
specified  maneuver  units  and  and/or  support  units;  and  the  number  of  each  job 
required  for  the  total  Army  to  provide  for  the  fielding  of  a  specified  number 
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of  systems.  Also,  optionally,  the  recommended  MOS  School  domain,  techno¬ 
logical  complexity,  and  competency  requirements  of  each  job  can  be  provided. 

TASK  AND  DATA  GENERATION  METHODOLOGY 

Task  Data  Requirement.  One  Input  requirement  to  the  Product  Five  process 
will  be  human  operator  and  malntalner  tasks.  It  Is  our  assumption  that  what  a 
person  does  Is  the  primary  determinant  of  the  characteristics  that  person  must 
possess  to  do  It.  The  determination  of  these  tasks  may  be  a  difficult 
problem,  since  at  the  time  Product  Five  Is  to  function  all  that  may  exist 
describing  the  soldier,  hardware  and  software  system  are  drawings  on 
blueprints  or  CRTs.  One  such  source  of  task  Information  will  be  the  Human 
Engineering  Design  Approach  Documents  for  operators  and  maintainers  (HEDAD-0 
and  HEDAD-M).  These  documents  describe  in  considerable  detail  (drawings,  time 
estimates,  and  textual  descriptions)  the  human  tasks  to  be  performed  in 
operating  and  maintaining  the  proposed  system.  Recent  major  material  RFPs 
(e.g,  LHX,  T800,  and  AFV)  have  required  that  the  HEDAD-0  and  HEDAD-M 
documentation  be  provided  very  early  In  the  design  process,  (i.e.  before 
down-select  or  prototype  development).  Because  of  the  importance  now  being 
assigned  to  MANPRINT  concerns.  It  Is  now  likely  that  most  weapon  system 
designs  will  have  HEDAD  Information  produced  early  In  their  development 
process.  Given  their  high  level  of  detail,  these  documents  will  be  excellent 
sources  of  task  Information  for  Product  Five. 

While  the  HEDAD-0  and  HEDAD-M  are  excellent  sources  of  task  descriptions 
and  Information,  we  recognize  that  Product  Five  may  from  time  to  time  be 
called  upon  to  evaluate  an  Interface  design  for  which  the  HEDAD  documents  have 
yet  to  be  completed.  To  provide  for  these  occasions  and  to  furnish  backup 
material  for  the  HEDAD-0  and  HEDAD-M,  we  will  develop  and  submit  as  an  adjunct 
to  the  Product  Five  evaluation  mechanism  a  design  Interface-to-human  task 
(operator  and  malntalner)  generating  mechanism.  The  advantage  of  this 
mechanism,  as  an  Input  to  the  evaluation  process,  is  that  It  will  always  be 
available. 

Other  sources  of  task  data  are  contained  as  elements  within  the  Early 
Comparability  Analysis  (ECA)  portions  of  the  HARDMAN  and  MIST  procedures. 
These  procedures  tend  to  group  tasks  Into  MOS  rather  than  jobs  or  duty 
positions  so  their  output  Is  at  a  higher  level  of  aggregation. 

Task  Generation  Capability.  Task  Analysis  is  a  time-oriented  description 
of  personnel  equipment  and  software  interactions  brought  about  by  an  operator, 
controller  or  malntalner  In  accomplishing  a  unit  of  work  with  a  system  or  Item 
of  equipment.  It  shows  the  sequential  and  simultaneous  manual  and  Intellectual 
activities  of  personnel  operating,  maintaining  or  controlling  equipment, 
rather  than  a  sequential  operation  of  the  equipment. 

The  analysis  of  tasks  will  provide  one  of  the  bases  for  evaluating  design 
decisions;  e.g.,  determinating,  to  the  extent  practicable,  before  hardware 
fabrication,  whether  system  performance  requirements  can  be  met  by  combination 
of  anticipated  equipment,  software,  and  personnel,  and  assuring  that  human 
performance  requirements  do  not  exceed  human  capabilities.  These  analyses  are 
also  used  as  basic  Information  for  developing  preliminary  manning  levels; 
equipment  procedures;  skill,  training  and  communication  requirements;  and 
Logistic  Support  Analysis  Inputs,  as  applicable.  The  gross  tasks  identified 
during  human  engineering  analysis,  which  are  related  to  end  items  of  equipment 
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to  be  operated  or  maintained  by  personnel  and  which  require  critical  human 
performance,  reflect  possible  unsafe  practices  or  are  subject  to  promising 
Improvements  In  operating  efficiency,  are  being  further  analyzed. 

Critical  performance  Is  that  human  performance  which,  if  not  accomplished 
In  accordance  with  system  requirements,  will  most  likely  have  adverse  effects 
on  cost,  system  reliability,  efficiency,  effectiveness,  or  safety.  Critical 
performance  Is  usually  part  of  a  "single"  line  of  flow  in  the  operation  or 
maintenance  cycle  of  the  system.  An  example  of  a  "single"  flow  Involving 
human  performance  Is  the  transmission  of  a  message  which  must  be  passed  for 
operations  or  maintenance  cycles  to  commence  or  to  continue,  such  as  an  order 
to  prepare  a  missile  for  launching.  If  this  order  is  not  passed,  or  If  It  Is 
garbled,  the  entire  missile  operation  cycle  may  cease  to  function  as  required. 
Human  performance  will  also  be  considered  critical  whenever  equipment  design 
approaches  limitations  (e.g.,  human  performance  functions  and  tasks  are  too 
demanding.  Information  presented  to  personnel  Is  Inadequate  to  meet  human 
performance  requirements,  appropriate  Information  displayed  Is  not  perceived, 
or  controls  provided  cannot  be  effectively  operated)  and  thereby  significantly 
contributes  to  the  occurrence  of  one  or  more  of  the  following  conditions  but 
not  necessarily  limited  thereto: 

(a)  Jeopardized  performance  of  an  authorized  mission. 

(b)  Degradation  of  the  circular  error  probability  (CEP)  to  an 
unacceptable  level. 

(c)  Delay  of  a  mission  beyond  acceptable  time  limits;  e.g.,  human  time 
to  react  will  not  meet  required  system  reaction  time. 

(d)  Improper  operation  resulting  In  a  system  "no-go,"  Inadvertent 
weapons  firing,  or  failure  to  achieve  operational  readiness  alert. 

(e)  The  exceeding  of  predicted  times  for  maintenance  personnel  and 
maintenance  ground  equipment  (MGE)  to  complete  maintenance  tasks. 
As  a  )ule,  performance  times  will  be  considered  critical  If  the 
total  maintenance  response  time  significantly  exceeds  maintenance 
analysis  estimates,  and  affects  MGE  quantitative  requirements. 

(f)  Degradation  of  system  equipment  below  reliability  requirements; 
l.e.,  mean  time  between  failures  (MTBF)  is  reduced. 

(g)  The  damaging  of  system  equipment,  resulting  either  in  a  return  to  a 
maintenance  facility  for  major  repair,  or  in  unacceptable  costs, 
spare  requirements,  or  system  downtime. 

(h)  A  serious  compromise  of  weapon  system  security. 

(1)  Injury  or  Illness  to  personnel. 

Analysis  of  Critical  Tasks.  Further  analysis  of  critical  tasks  will 
Identify  the:  (1)  information  required  by  operator  and  maintainer,  including 
cues  for  task  Initiation;  (2)  Information  available  to  operator  and 
maintainer;  (3)  evaluation  process;  (4)  decision  reached  after  evaluation;  (5) 
action  taken;  (6)  body  movements  required  by  action  taken;  (7)  workspace 
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envelope  required  by  action  taken;  (8)  workspace  available;  (9)  location  and 
condition  of  the  work  environment;  (10)  frequency  and  tolerances  of  action; 
(11)  time  base;  (12)  feedback  informing  operator/maintainer  of  the  adequacy  of 
action;  (13)  tools  and  equipment  required;  (14)  number  of  personnel  required, 
their  specialty  and  experience;  (15)  job  aids  or  references  required;  (16) 
communications  required,  including  type  of  communication;  (17)  special  hazards 
Involved;  (18)  operator  interaction  where  more  than  one  crew  member  is 
involved;  (19)  operational  limits  of  personnel  (performance);  and  (20) 
operational  limits  of  machine  and  software.  The  analysis  will  be  performed 
for  all  affected  missions  and  phases  Including  degraded  modes  of  operation. 

Task  Analysis  Hierarchy.  The  following  hierarchy  Is  used  to  Inventory  or 
analyze  tasks,  with  levels  (a)  and  (b)  stated  by  the  procuring  activity  and 
the  remaining  levels  dependent  on  the  current  phase  of  system  development  and 
purpose  (e.g.,  gross  analysis  of  tasks,  analysis  of  critical  tasks)  for  which 
the  analysis  Is  being  conducted  (Zavala,  1980). 

(a)  Mission  -  What  the  system  Is  supposed  to  accomplish,  e.g.,  combat 
reconnaissance. 

(b)  Scenario  and  Conditions  -  Categories  of  factors  or  constraint  under 
which  the  system  will  be  expected  to  operate  and  be  maintained, 
e.g.,  day  and  night,  all  weather,  all  terrain  operation. 

(c)  Function  -  A  broad  category  of  activity  performed  by  a  system,  e.g., 
transportation. 

(d)  Job  -  The  combination  of  all  human  performance  required  for 
operation  and  maintenance  of  one  personnel  position  In  a  system, 
e.g.,  driver. 

(e)  Duty  -  A  set  of  operationally-related  tasks  within  a  given 

e.g.,  driving,  weapon  servicing,  communicating,  target  detection, 
self  protection,  operator  maintenance. 

(f)  Task  -  A  composite  of  related  activities  (perceptions,  decisions, 

and  responses)  performed  for  an  Immediate  purpose,  written  in 
operator  and  malntalner  language. 

(g)  Sub-task  -  Activities  (perceptions,  decisions  and  responses)  which 
fulfill  a  portion  of  the  Immediate  purpose  within  a  task. 

(h)  Task  Element  -  The  smallest  logically  and  reasonably  definable  unit 
of  behavior  required  In  completing  a  task  or  sub-task. 

Task  Analyses  Generation.  Product  Five  is  conceptualized  to  have  the 
capability  to  transfer  or  create  task  analysis  information  for  storage  in  its 
data  management  system  In  the  task  hierarchy  discussed  above.  The  transfer 
function  of  the  task  analysis  generator  is  provided  to  convert  available  task 

analysis  data  In  model  forms,  such  as  HOS,  MICROSAINT,  and  Modified  Petri  Net 

(MPN)  System.  This  conversion  Is  accomplished  by  ACS  1 1  processing.  We  have 
already  written  code  for  this  conversion  for  MICROSAINT.  The  Army  Human 
Engineering  Laboratory  Is  developing  Perceptronics  MPN  for  MANPRINT  evalu¬ 
ation.  The  major  point  to  be  made  is  that  Product  Five  will  be  usable  by  Army 
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MANPRINT  personnel  at  different  locations  without  restricting  the  task 
analysis  technique,  workload  model,  or  user's  preference. 

The  second  function  of  the  task  generator  is  to  create  the  information. 
This  creation  of  task  analysis  Information  is  accomplished  by  the  user 
Interacting  with  the  user  Interface  system  and  adaptive  protocols.  The 
tabular  format  of  the  task  analysis  contains  the  following  Information:  (1) 
Function  Sequence  -  Identifies  the  functional  block  for  this  task  sequence; 

(2)  Task  and  Sub-task  Numbers  -  Identifies  that  specific  task  with  the  given 
sequence;  (3)  Task  Element  Descriptions  -  describes  the  specific  task  to  be 
done;  (4)  Estimated  Task  Time;  (5)  Accumulated  Task  Time;  (6)  Task  Critically 
-  relative  Importance  of  task  to  the  completion  of  the  mission  and  scenario 
and  conditions;  (7)  Operator  Control  and  Display,  or  Maintainer  Equipment, 
Description;  (8)  Operator  Panel  Location,  or  Maintainer  Equipment,  Location 
(zone)  (e.g..  Identifies  panel  where  switch  or  control  Is  located);  and  (9) 
Task  Element  Sensory  and  Motor  Load,  l.e.,  visual,  right  hand,  left  hand, 
communications,  or  feet;  and  (10)  Task  element  information  processing, 
cognitive,  or  decision  load.  These  are  required  data  to  establish  the  task 
requirements  related  to  each  mission  and  scenario  and  conditions. 

Network  Methodology.  Prior  to  generating  the  task  information  above,  the 
user  has  the  ability  built  in  the  Product  Five  system  to  create  task  (block) 
networks.  This  capability  is  critical  since  the  sequential  or  parallel 
relationship  to  other  tasks  is  important  data  for  this  aid.  A  network 
consists  of  one  or  more  sets  of  connected  task  or  sub-task  blocks.  This  task 
level  of  network  flow  Is  adequate  for  the  experienced  modeler  upon  which  to 
build  the  task  input  statement  information.  Each  block  describes  a  task  or 
sub-task  in  terms  of  stimulus-  organism-response  (S-O-R)  data  elements.  All 
(S-O-R)  data  elements  must  be  accounted  for,  explicitly  or  implicitly,  in  the 
network.  A  block  contains  any  or  all  of  the  following  personnel  functions. 

(1)  Time  delay  elements. 

(2)  Task  1  element  (visual  or  auditory)  -  STIMULUS. 

(3)  Information  processing  element  -  ORGANISM. 

(4)  Task  2  element  (right-hand,  left-hand,  feet,  or  communication)- 
RESPONSE. 

In  addition  to  the  above,  a  task  block  also  includes  the  following  elements: 

(1)  Human  probability  decision  points  following  the  task  1,  information 
processing,  and  task  2  elements. 

(2)  Equipment  probability  decision  points  following  the  task  1  and  task 
2  element. 

(3)  A  task  recycle  probability  decision  point. 

(4)  Predecessor  and  Successor  task  blocks  corresponding  to  the  points 
where  a  block  may  be  entered  or  exited. 

(5)  Attribute  values  (e.g.,  means,  standard  deviations). 
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WORKLOAD  GENERATOR 


Perceptronlcs  MPN  Workload  Model.  Task  analysis  can  be  performed  for 
many  different  purposes  (e.g.,  development  of  job  aids,  functional  allocation, 
performance  and  workload  prediction,  training,  training  material  and  training 
aids  development,  and  man-machine  interface  design).  Typically,  different 
task  analytic  approaches  have  been  brought  to  bear,  depending  upon  the 

specific  purpose  of  task  analysis.  The  MPN  model-based  approach  is  unique 
because  It  addresses  each  of  the  purposes  for  task  analysis  required  by 

advanced  weapon  system  design.  For  example,  using  MPN  analysis,  strong 
guidelines  can  be  derived  for  function  allocation.  A  good  approximate 
analysis  for  sound  performance  and  workload  comparisons  of  alternative 
function  allocation  options  can  also  be  performed.  Man-machine  interface  load 
can  also  be  studied  within  the  MPN  framework  geared  to  describing  tasks  at  the 
man-machine  interaction  level.  Finally,  the  MPN  model  can  also  be  used  to 
simulate  expert  performance  and  behavior  In  Intelligent  tutoring  systems  (ITS) 
for  developing  Intelligent  Training  Delivery  systems.  In  the  following 
paragraphs,  the  various  applications  of  the  MPN  model  for  the  workload 

prediction  and  assessment  will  be  described  in  terms  of  Inputs,  outputs, 

processes  and  the  specific  knowledge  that  can  be  embodied  depending  upon  the 
specific  requirements  of  the  application. 

The  MPN  model  Is  a  network  of  human  Information  processing  tasks  or 
activities  (perceptual,  cognitive,  and  psychomotor)  and  events  (internal  or 
external  to  the  man-machine  system)  In  which  the  possible  precedence  of 
variables  among  activities  and  events  can  be  parsimoniously  represented.  In 
addition,  the  network  model  is  an  active,  executable  model  capable  of 
describing  and  predicting  human  performance  and  workload  under  different 
environmental,  task,  and  function-allocation  conditions.  The  active  property 
of  the  MPN  framework  arises  from  the  fact  that  It  is  a  token-marked  graph.  As 
the  net  executes,  a  token  propagates  In  response  to  external  or  Internal 
events.  Token  propagation  is  defined  by  token  propagation  rules.  Token 
propagation  patterns  provide  a  well-defined  trace  or  audit-trail  to  which 
explanations  can  be  linked  in  a  clear  fashion. 

Uses  of  the  MPN  Models.  The  MPN  analysis  will  be  used  in  six  different 
ways  within  the  workload  analysis:  (1)  as  a  means  for  determining  all 

possible  task  concurrencies,  (2)  as  an  initial  guide  to  function  allocation, 
(3)  as  a  means  to  verify  the  reasonableness  of  data  generated  from  manned, 
part  mission  part-task  simulation,  (4)  to  evaluate  alternative  automation 
concepts  and  man  machine  Interfaces,  (5)  as  a  "driver"  of  selected  nodes  in 
mission  characteristics  models,  and  (6)  to  provide  a  rationale  for  human 
performance  and  workload  prediction  function  allocation.  Each  of  these  uses 
Is  described  In  the  following  paragraphs. 

(1)  MPN-Based  Task  Concurrency  Analysis.  One  of  the  problems  in  task 
analysis  Is  determining  what  tasks  are  frequently  performed 
simultaneously.  This  has  obvious  implications  for  identifying 
high-workload  situations  and  for  suggesting  possible  options  for 
functional  allocation.  To  this  end,  the  MPN-model  will  be  executed 
in  a  Monte  Carlo  mode  to  expose  all  the  possible  task  concurrencies. 
An  Important  by-product  of  concurrency  analysis  is  in  elicitation  of 
workload  for  both  Individual  and  concurrent  tasks.  Experience  shows 
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that  tasks  that  are  structually  dependent  in  terms  of  skills  or  that 
share  human  resources  do  not  produce  additive  workload.  This 
appears  to  be  because  the  human  operator  tends  to  sacrifice 
performance  on  one  task  to  perfrom  all  tasks  acceptably.  Eliciting 
the  workload  for  all  such  concurrent  tasks  gives  a  far  more  accurate 
picture  when  the  MPN  model  is  executed  for  workload  and  performance 
predictions  (Madnl,  1985).  It  has  also  been  shown  that  even 
experienced  pilots  cannot  supply  all  the  task  concurrencies  that  can 
occur  In  a  typical  mission  scenario.  Consequently,  the  use  of  MPN 
to  this  end  is  a  major  contribution  to  the  task  process. 

(2)  MPN  Analysis  for  Function  Allocation.  In  this  analysis,  the  tasks 
are  encoded  within  Modified  Petri  Nets  at  a  level  of  abstraction 
that  allows  Identlf ication  of  whether  the  tasks  are  predominantly 
perceptual,  cognitive,  or  psychomotor  in  nature.  The  Input  data  at 
this  point  is  the  event  stream  from  an  event  sequencer  and  times 
elicited  from  experts.  The  MPN  models  are  executed  in  Monte  Carlo 
mode  and  workload  and  performance  envelopes  are  computed  for  the 
total  task.  Following  this,  the  subnets  associated  with  each 
concurrent  path  are  executed  in  a  "What-if"  mode  directed  at 
extraction  of  the  fractional  contribution  of  each  concurrent  path 
(activity  sequence)  to  the  overall  task.  This  process,  which 
determines  the  partial  contributions  of  each  activity  sequence  with 
respect  to  the  overall  task,  is  capable  of  providing  strong 
guidelines  for  candidate  function-allocation  schemes.  The  use  of 
this  information  in  conjunction  with  the  suitability  of  the  machine 
to  perform  these  tasks  provides  a  sound  basis  for  developing  and 
testing  alternative  function  allocation  options. 

(3)  MPN  as  a  Verification  Tool  for  Part-Task  Simulations.  In  this 
capacity,  the  MPN  model  is  driven  by  the  actual  scenario  events 
recorded  in  the  manned,  part- task  simulation.  The  MPN  model  is 
executed  and  the  performance  and  workload  results  are  compared 
against  protocol  analysis.  On  the  one  hand,  this  process  verifies 
the  results  of  the  part-task  simulation  and,  on  the  other,  suggests 
guidelines  for  expanding  the  MPN  model  to  the  lower  levels  of 
abstraction  required  for  candidate  automation  concept  evaluation  and 
comparison  of  man-  machine  interface  options. 

(4)  MPN  Models  for  Evaluation  of  Automation  Concepts  and  Man-Machine 
Interfaces.  In  this  capacity,  the  MPN  models  are  developed  in 
detail  at  multiple  levels  of  abstraction  to  evaluate  the  performance 
and  workload  resulting  from  alternative  automation  concepts  and  man- 
machine  interfaces.  At  the  lowest  level  in  the  MPN  hierarchy,  the 
activities  are  the  specific  actions  of  the  human  via  a  specific 
control  input  or  in  response  to  a  specific  display  generated  by  the 
automation. 

(5)  MPN-Based  for  Mission  Characterization  Model.  The  MPN  model  in  this 
capacity  can  be  used  to  provide  selected  performance  statistics  for 
the  mission  characterization  model,  which  is  a  network  of  different 
types  of  nodes  (equipment,  humans,  etc.)  with  their  associated 
probabilities  of  contributions  to  overall  mission  success. 
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Performance  statistics  can  be  generated  by  the  MPN  analysis  to 
investigate  the  impact  of  any  selected  note  on  mission  success. 

The  MPN-based  analysis  approach  provides  a  consistent  framework  for: 


(a)  Identifying  the  possible  task  concurrencies  in  the  course  of  a 
mission  scenario. 

(b)  Guiding  the  development  of  function  allocation  options. 

(c)  Evaluating  the  Impact  of  different  function  allocation  options  on 
operator  performance  and  workload. 

(d)  Evaluating  the  efficiency  of  alternative  automation  concepts  and 
human-machine  Interfaces. 

(e)  Predicting  overall  workload  and  performance  associated  with 
critical  mission  segments. 

(f)  Providing  performance  statistics  for  mission  characterization 
model . 

(6)  Rationale  for  MPN-Based  Human  Performance  and  Workload  Prediction 
for  Function  Allocation.  In  order  to  predict  human  performance  and 
workload,  specific  scenarios  must  be  addressed.  Given  a  scenario, 
the  Interactions  of  the  human  and  machine  need  to  be  captured  in 
both  a  descriptive  and  prescriptive  sense.  The  former  is  necessary 
so  that  all  the  relevant  dimensions  can  be  laid  out  for 

consideration  by  the  human  or  automated  tools  attempting  to  predict 
the  behavior  of  the  human  working  with  the  machine.  The  latter  is 
necessary  because  it  is  difficult  for  the  human  designer  to  predict 
performance  In  an  uncertain  environment  given  the  different  problem 
dimensions. 

This  leads  to  the  need  for  a  prescriptive  tool.  From  the 

descriptive  and  prescriptive  requirements  stem  three  key  criteria 
for  adopting  a  human  performance  and  workload  prediction  tool. 
First,  it  is  necessary  for  the  approach  to  be  model-based  if  the 

subjectivity  in  these  assessments  is  to  be  reduced.  At  the  heart  of 
the  model -based  approach  is  the  representation  of  all  task-related 
knowledge.  Second,  If  the  tool  is  expected  to  prescribe  or  predict, 
it  can  only  do  so  If  it  is  in  the  form  of  an  executable  piece  of 
software.  In  other  words,  the  representation  has  to  be  dynamic,  not 

static.  Third,  If  the  tool  is  expected  to  be  used,  it  should  be 

verifiable  against  simulator  data,  laboratory  experiments,  and 
flight  tests.  This  calls  for  a  model  that  is  "glass-box"  rather 
than  "black  box"  In  nature. 

Of  the  various  disciplines  that  have  attempted  to  tackle  this  problem, 
the  most  prominent  have  been  cognitive  psychology  and  decision  analysis, 

operations  research  and  control  theory,  and  artificial  intelligence  and  expert 
systems.  Cognitive  psychology  provides  principles  for  human  behavior  in 
decision-making  contexts.  Belief  that  humans  confuse  objectives  and  options, 
fixate  upon  the  most  recent  piece  of  information  Inadvertently  impose 
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constraints  on  the  problem  that  sometimes  pre-empts  creative  option 
generation,  and  tend  to  be  poor  aggregators  of  information,  is  the  legacy  of 
cognitive  and  behavioral  psychology.  However,  there  is  no  formal  or  unifying 
representation  within  cognitive  psychology  that  satisfies  the  requirements  of 
rich  description,  prescription  (via  executable  software),  and  verifiability. 
Therefore,  while  cognitive  psychology  provides  vital  Insights,  it  does  not 
provide  a  modeling  framework  for  prescription  analysis. 

Decision  analysis  offers  a  normative  framework  for  problem-structuring, 
option  evaluation,  and  option  selection.  Specifically,  Multi-Attribute 
Utility  (MAU)  models  and  decision  trees  are  two  useful  modeling  frameworks. 
MAU  models  are  highly-sultable  for  characterizing  mission  goals  and  tradeoffs 
among  the  objectives  that  characterizes  the  attainment  of  the  goal.  However, 
they  are  not  a  static  framework  capable  of  capturing  explicit  events,  task 
concurrencies  and  uncertainties  associated  with  air  combat  tasks.  Decision 
trees  provide  a  convenient  means  for  structuring  the  problem  and  for  function 
allocation  and  automation.  Operations  research  techniques,  such  as  linear 
programming,  have  seen  some  use  in  decision  aids  for  resource  allocation. 
However,  linear  programming  techniques  solve  static  optimization  problems  that 
do  not  characterize  air  combat  tasks. 

Perhaps  the  most  significant  contribution  of  operations  research  is  the 
GERT  and  Q-GERT  type  network  models  that  produced  analysis  software  such  as 
SAINT  and  SLAM  and  their  micro-based  versions.  These  techniques  have  been 
used  by  some  of  the  major  airframe  manufacturers  for  task  and  workload 
analysis.  However,  these  techniques  typically  have  one  major  shortcoming. 
They  lack  explicit  handling  of  the  cognitive  component  in  task  performance. 
This  Is  not  surprising  because,  at  the  time  these  models  were  developed, 
automation  and  AI  and  expert  systems  technology  were  not  far  enough  along  to 
make  cognitive  modeling  a  viable  goal.  In  addition,  since  they  operate 
primarily  through  the  SAINT-  and  SLAM- type  models  they  tend  to  be  somewhat 
tedious  and  provide  a  batch  rather  than  a  truly  interactive  process.  Finally, 
the  user  Interface  needs  significant  improvement  In  these  software  models. 

A  key  contribution  of  control  theory  is  optimal  control  models  of  the 
human  operator.  While  these  models  are  highly  suitable  for  tracking  tasks  and 
strike  sequencing  problems,  they  are  incapable  of  handling  the  cognitive 
contribution  to  the  problem  except  In  an  input-output  sense  which  leads  to  the 
■black-box"  representation  of  the  problem.  The  lack  of  transparency  and 
correspondence  with  physical  reality  make  these  classes  of  models  highly 
unsuitable  as  an  analytic  tool  for  making  task  performance  and  workload 
assessments.  This  brings  us  to  AI  and  the  attendant  knowledge  representation 
techniques  associated  with  expert  systems  development.  These  techniques 
Include  production  rules,  frames,  propositional  and  predicate  calculus, 
scripts,  associative  and  semantic  nets,  directed  graphs,  AND/OR  graphs  and 
network  models.  Most  of  these  techniques  capture  some  aspect  of  the  problem 
such  as  relationships,  conditions,  causality,  precedence,  or  events.  However, 
when  requirements  of  parsimony,  executabil Ity,  and  representation  power  are 
applied,  none  of  these  methods  Independently  achieve  these  ambitious  goals. 
For  example,  production  rules  with  procedural  attachments  can  capture  all 
aspects  of  behavior  (l.e.,  both  the  what  and  how)  but  typically  tend  to  grow 
combinatorial ly,  thereby  violating  the  requirement  of  parsimony.  In  addition, 
as  the  size  of  the  rule  set  Increases,  ad  hoc  methods  have  to  be  brought  to 
bear  to  limit  the  sampling  of  just  the  relevant  rule  set  in  the  face  of 
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changing  environmental  conditions.  Similar  problems  exist  with  some  of  the 
other  techniques.  The  modeling  approach  that  satisfies  the  requirements  of 
representation  power,  executability,  and  verifiability  along  with  parisimony 
and  tractability  are  Modified  Petri  Nets.  These  models  developed  by  Madni  et 
al.,  (1984)  build  on  the  original  work  of  Petri  In  1961.  These  models  possess 
the  characteristics  summarized  in  Table  3. 


Table  3.  Modified  Petri  Net  (MPN)  Capabilities 
For  Operator  Combat  Task  Analysis 

Representation  Power 
Decisions 

Events  and  Associated  Ucertainties 

Concurrent  and  Asynchronous  Tasks  and  Processes 

Priorities 

Activities  (Perceptual,  Cognitive,  Motor) 

Time  tied  to  Occurrence  of  Events 

Variable  Precedence  Among  Events  and  Activities 

Multiple  Levels  of  Abstraction 

Prescriptive  Power 

"Executable"  Network  Software 
Workload  Envelopes  and  Comparisons 
Performance  Envelopes 

Verifiability 

Against  Manned  Simulations 
Laboratory  Experiments 
Flight 

Explanation  Power 

Audit  Trail  Maintained  via  Token  Propagation 
Patterns  Explanations  Specifically  Tied  to  Tokens 


JOB  COMPONENT  AGGREGATION:  MEASURES  AND  ALGORITHMS 

The  clustering  algorithms  that  operate  on  t  ther  0/1  or  S/U  matrices  are 
straight  forward,  neither  providing  appreciable  developmental  or  acceptability 
risk,  nor  offering  to  dramatically  extend  the  state  of  the  art.  It  is  the 
content  of  the  0/1  and  S/U  matrices  that  pose  the  greater  problems  and 
opportunities  to  exercise  creativity.  It  is  the  proposed  and  alternative 
approaches  for  arriving  at  values  for  the  cells  of  those  matrices  and  the 
values  for  the  technological  complexity  and  boundary  violation  variables  for 
each  job  component  that  will  be  discussed  in  this  section.  However,  since  the 
nature  of  the  competency  variable  depends  so  heavily  on  the  design  and  use  of 
the  data  bank,  all  measurement  issues  relating  to  competencies  will  be 
discussed  later  under  the  data  bank  topic. 

The  Methodological  Confidence  Continuum— From  the  Fully  Determined  to  the 
Relatively  Unknown.  The  confidence  placed  in  the  overall  soundness  of  ^he 
methodology  associated  with  the  variables  used  in  the  aggregation  process  vary 
with  respect  to  several  dimensions.  These  dimensions  include  the  following: 
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(1)  Quality  of  metric. 

(2)  Certainty  that  values  for  the  variable  can  be  validly  and  reliably 
estimated. 

(3)  Face  valid  relevance  of  the  variable  to  the  decision  it  is 
influencing  (relevance) . 

(4)  Closeness  of  the  variable  to  the  ultimate  utility  function  (validity 
against  the  ultimate  criterion). 

The  Rank  Order  Is  Important.  Such  variables  as  technological  complexity 
and  task  performance  frequency  can  be  ranked  on  each  of  the  above  four 
dimensions.  These  rank  orders  are  provided  In  Figure  14  for  a  number  of 
variables  using  A  as  best  (deserves  the  most  confidence),  B  as  upper 
Intermediate,  C  as  lower  Intermediate  and  D  for  those  tied  at  the  bottom  of 
the  rank  order.  Since  these  letters  represent  rank  order,  rather  than  an 
evaluation,  at  least  one  variable  will  have  a  D  on  each  dimension.  The 
dimensions  are  represented  in  Figure  14  by  the  underlined  words  in  the  above 
descriptions.  The  top  variable  in  Figure  14  has  the  highest  overall  rank 
order  just  as  the  bottom  variable  has  the  lowest  overall  rank  order  on  the 
confidence  continuum. 

Consequences  for  development  of  a  low  rank  order  displayed  in  Figure  14 
is  not  in  itself  an  argument  for  the  deletion  of  a  variable  from  Product  Five. 
Instead,  such  a  ranking  Indicates  the  need  for  special  attention  to  such  a 
variable  during  the  developmental  process.  The  means  of  defining  and  placing 
values  on  the  lower  ranking  variables  will  be  discussed  at  greater  length  than 
those  variables  that  ranked  at  the  top  of  Figure  14. 

Alternative  Approaches  Considered  and  Rejected.  Determination  of  task 
similarity  in  terms  of  system  and  sub-system  and  technology  simularities  was 
addressed.  The  need  for  a  clustering  process,  as  in  the  clustering  of  tasks 
Into  jobs.  Immediately  brings  to  mind  the  principle  of  placing  like  things 
together.  To  do  this  a  similarity  measure  is  required.  If  a  relevant 
similarity  measure  can  be  credibly  identified;  one  that  also  passes  muster 
with  respect  to  its  metric  quality,  reliability,  validity  with  respect  to  a 
utility  function,  and  relevance  to  Army  doctrine  and  MANPRINT  objectives--then 
traditional  algorithms,  for  maximizing  similarity  within  clusters  and 
minimizing  similarity  across  clusters,  can  be  utilized. 

One  similarity  measure  considered  for  use  was  the  degree  of  commonality 
with  respect  to  systems  and  sub-systems  and  relevant  technology  for 
maintenance  tasks,  and  with  respect  to  missions,  functions,  and  activities  for 
operator  tasks.  Such  a  measure  received  a  very  poor  evaluation  for  its  metric 
quality  and  its  lack  of  relationship  to  an  important  underlying  utility 
function.  Such  a  similarity  measure  does  not  assure  that  a  soldier  who  can 
perform  well  on  a  given  task  can  be  expected  to  perform  well  on  "similar" 
tasks.  Nor  can  one  be  reasonably  certain  that  training  time  is  reduced 
proportionately  to  the  Increase  of  task  homogeneity  within  a  cluster.  The 
metric  appeared  to  yield  an  ordinal  scale  rather  than  the  interval  scale 
needed  to  compare  increments  In  a  measure  of  similarity  across  clusters  and 
iterations.  For  those  reasons  a  S/U  measure  more  clearly  related  to  a 
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RANK  ORDER*  OF  AGGREGATION  VARIABLES 
FOR  FOUR  DIMENSIONS  AFFECTING  CONFIDENCE 


Overall 

Rank  Dimensions  Affecting  Confidence 

Order  Aggregation  Variables  (see  text  for  definitions) 

Metric  Reliability  Validity  Relevance 


1  Time  to  Perforin  Task  A 

2  Frequency  of  Task  Performance  A 

3  Enabling  Skills  Training  Time  B 

4  Task  Level  Skills  Training  B 

Time 

5  Generic  Task  Skills  Training  B 

Time 

6  Importance  Weighting  C 

7  Technology  Complexity  D 

3  Learning  Decay  Rate  C 

9  Training  Transfer  Rate  C 

10  MOS/School  Boundary  Violations  D 


C 

C 

A 

B 

B 

C 

C 

D 

D 

A 


A 

A 

C 

C 

C 

C 

B 

B 

C 

D 


A 

A 

B 

B 

C 

A 

A 

B 

C 

D 


*"A"  indicates  that  variable  Is  tied  at  the  high  end  of  the  confidence 
continuum,  D  represents  the  low  end. 


FIGURE  14.  Rank  Order  of  Aggregation  Variables 
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desirable  utility  function  was  sought,  eventually  leading  to  the  consideration 
of  the  S/U  measure  and  algorithm  proposed  in  this  report. 

The  use  of  a  Simulation  Model  was  also  addressed.  A  simulation  model  to 
estimate  system  performance  with  different  numbers  of  operators  and 
malntalners  could  conceivably  be  used  in  a  series  of  "what  if"  experiments,  to 
obtain  the  number  of  soldiers,  and  a  division  of  labor  within  the  system  that 
would  Identify  jobs— both  being  accomplished  with  the  degree  of  specificity 
permitted  by  the  parameters  of  the  simulation  model.  For  example,  the  ARI 
MANMODEL  would  permit  the  determination  of  system  performance  with  various 
manning  configurations  in  TO S  (the  division  and  corp  level  command  and  control 
system  proposed  for  development  about  ten  years  ago).  The  Navy  "ships"  model 
would  have  provided  similar  data  for  both  operator  and  maintenance  tasks  on  a 
specified  type  of  destroyer. 

The  major  problem  with  this  approach  lies  in  the  virtual  Impossibility  of 
creating  a  general  simulation  model  that  can  provide  system  performance 
estimates  for  alternative  manning  configurations  across  widely  different 
systems.  The  cost  of  providing  different  MANMODEL  type  simulation  models  for 
such  systems  as  FAADS,  the  Bradley,  a  self  propelled  howitzer,  a  light  machine 
gun,  etc.,  for  over  a  dozen  widely  different  systems  would  be  prohibitive. 
The  ARI  SIMPO  program  provides  some  examples  of  potential  pitfalls  associated 
with  the  development  of  overly  general  models.  This  program  had  the  objective 
of  creating  a  "General  Matrix  Generator"  model  that  would  avoid  the  necessity 
of  programming  custom  designed  network  flow  models  to  solve  each  problem  posed 
by  a  sponsor.  As  other  organizations  have  also  discovered  in  other 
situations,  It  turned  out  to  be  just  as  fast  to  write  a  new  program  to 
implement  a  custom  designed  model  as  compared  to  the  effort  required  to 
manipulate  the  parameters  on  the  "general"  model— plus,  the  custom  designed 
models  were  typically  20  times  faster  than  the  general  model.  It  should  be 
noted  that  these  problems  were  occurring  with  relatively  similar  situations  to 
be  modeled,  as  compared  to  the  diversity  in  mission,  function  and  technologies 
that  will  occur  among  the  new  systems  that  Product  Five  will  be  applied  to 
over  a  3  year  time  span. 


TECHNOLOGICAL  COMPLEXITY 

Investigators  conducting  MANPRINT  analyses  for  industry  have  noted  that 
the  Army  has  several  criteria  for  determining  Aptitude  Area  "cut  scores"  for 
Army  School  Applicants— In  addition  to  the  perceived  cognitive  loading  of  the 
tasks  to  be  performed.  One  of  these  criteria  appears  to  be  the  complexity  and 
technical  sophistication  of  the  systems  with  which  the  incumbents  work.  This 
criterion  is  the  variable  that  is  referred  to  as  technological  complexity  in 
this  concept  paper. 

It  was  noted  that  the  S/U  measure  proposed  for  use  in  Product  Five  is 
closely  related  to  technological  complexity.  When  more  enabling  skills  and 
higher  level  task  skills  are  required  to  accomplish  a  job  component,  upon  the 
merger  of  two  tasks  to  form  this  component,  the  increased  demand  being  made  on 
the  Incumbent  appears  to  be  similar  to  the  demands  that  increasing  the 
technological  complexity  of  the  system  would  make.  However,  it  is  believed 
that  a  maximum  3/U  measure  score  and  a  maximum  score  reflecting  the 
technological  complexity  of  the  system(s)  should  be  separately  considered  by 
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the  analyst  in  determining  the  acceptability  of  a  particular  cluster  of  tasks 
(as  a  duty  module  or  job).  Most  job  component  mergers  will  Increase  both  the 
S/U  measure  value  and  the  technologlral  complexity  score  when  compared  to 
either  of  the  two  components  considered  separately.  Since  the  "best"  pair  of 
candidate  components  is  selected  on  the  basis  of  maximizing  the  S/U  gain  (the 
difference  between  the  sum  of  the  two  constituant  components,  S/U  measure 
values  and  the  S/U  measure  value  for  the  merged  component— this  difference 
then  multiplied  by  (-1)),  the  steadily  increasing  S/U  measure  and/or  the 
steadily  Increasing  technological  complexity  score  could  reach  an  unacceptable 
level  before  the  workload  threshold  or  minimum  gain  increment  is  reached. 
Thus,  It  is  essential  to  provide  the  analyst  the  option  of  setting  threshold 
values  for  either  or  both  variables  (S/U  measure  value  and/or  technological 
complexity  score)  that  will  be  used  to  test  the  acceptability  of  each  merger 
selected  as  "best"  by  the  aggregation  algorithm. 

Measurement  of  Technological  Complexity.  The  assignment  of  a  techno¬ 
logical  complexity  score  will  be  accomplished  in  two  steps:  (1)  the  Identifi¬ 
cation  and  selection  of  technological  dimensions  and  categories  considered  to 
be  relevant  to  the  set  of  tasks  to  be  aggregated,  and  (2)  the  assignment  of 
complexity  scores  to  each  task  for  each  relevant  dimension  and  category.  A 
decision  aid  will  provide  prompts  and  aiding  for  both  processes.  A  technology 
data  bank  file  will  be  referenced  by  the  decision  aid  during  the  first  step 
and  the  selected  dimensions  and  categories  placed  on  a  working  file  that  will 
in  turn  be  utilized  in  step  2  for  the  recording  of  complexity  scores  assigned 
by  the  analyst.  This  working  file  will  then  be  used  during  the  aggregation 
process  for  each  Iteration  for  which  the  analyst  chooses  to  use  the 
technological  complexity  option. 

The  technological  dimensions  and  categories  found  in  the  data  bank  file 
may  sometimes  be  adequate  for  the  Product  Five  analysis  of  a  set  of  tasks 
without  the  use  of  additional  custom  made  dimensions  and  categories  (D/C).  A 
useful  D/C  must  be  present  In  some  tasks  and  not  In  others  that  are  eligible 
for  aggregation.  Any  D/C  that  cuts  across  all  the  tasks  under  consideration 
will  obviously  contribute  nothing  to  the  analysis.  Thus,  the  analyst  will 
frequently  wish  to  add  additional  D/Cs  that  represent  subcategories  of 
technology  within  some  of  the  broader  D/Cs  found  In  the  data  bank  file.  Each 
such  custom  made  D/C  should  have  sufficient  Independence  of  all  others 
selected  to  permit  the  assumption  that  an  average  score  (e.g.,  10)  over  any 
set  of  N  D/Cs  represents  more  technological  complexity  than  would  that  same 
average  score  over  any  set  of  N-l  D/Cs. 

After  selection  of  an  appropriate  set  of  D/Cs,  the  analyst  will  review 
and  confirm  the  relative  complexity  of  D/Cs  as  recorded  In  the  data  bank  file. 
For  the  new  D/Cs  the  analyst  will  assign  a  comparable  D/C  complexity  score 
(Independent  of  the  complexity  level  at  which  that  D/C  is  required  In  each 
separate  task). 

A  decision  aid  will  provide  prompting  and  decision  aiding  to  the  analyst 
for  the  assignment  of  complexity  scores  to  each  combination  of  task  and 
relevant  D/C.  This  process  will  take  into  consideration  factors  that  also 
contributed  to  the  D/C  complexity  scores  including  the  following:  (1)  the 
general  maturity  of  the  science  or  technology  as  applied  to  the  type  of  system 
at  Issue:  (2)  the  extent  the  technology  is  commonly:  (a)  not  even  introduced, 
(b)  Introduced,  or  (c)  well  covered— at  various  educational  levels  ranging 
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from  eighth  grade  general  science,  through  High  School  science  courses  in  1 
year  technology  programs,  to  college  level  science  courses.  In  addition,  more 
task  specific  factors  such  as  the  depth  of  the  D/C  required  to  perform  each 
task  and  the  degree  to  which  the  incumbent  will  be  shielded  from  needing  to 
understand  the  technology  (e.g.  by  decision  aids  and/or  other  job  aids). 

Use  of  Technological  Complexity  In  the  Aggregation  Process.  The 
technological  complexity  score  for  a  cluster  of  tasks  (a  job  component,  duty 
module,  or  job)  Is  obtained  by  first  concatenating  the  sets  of  D/C's  attached 
to  each  of  the  constituent  tasks,  the  complexity  scores  attached  to  each  D/C 
In  the  resultant  set  are  summed.  This  sum  is  the  technological  complexity 
score  for  the  task  cluster. 

The  computation  of  a  technological  complexity  score  for  a  job  component, 
after  the  analyst  has  assigned  his  task-D/C  technology  scores,  is  accomplished 
In  a  manner  that  Is  completely  parallel  to  the  computation  of  a  S/U  measure 
for  a  job  component.  As  with  a  S/U  measure,  the  technological  complexity 
score  for  a  merged  composite  Is  always  equal  to  or  greater  than  the  sum  of  the 
technological  complexity  scores  of  the  constituent  composites. 

Since  the  "best"  pair  of  candidate  components  is  the  pair  with  the 
largest  S/U  gain,  and  the  largest  gain  implies  (in  general)  the  smallest 
Increase  in  S/U  value  resulting  from  a  trial  merger,  the  trend  is  for 
successively  larger  Increments  In  the  S/U  value  (before  computing  the 
difference)  through  successive  Iterations.  A  similar  increase  in  the 
magnitude  of  technological  complexity  score  increments  can  be  expected  in 
successive  Iterations. 

The  Role  of  Technological  Complexity  In  the  Aggregation  Process.  The 
analyst  has  the  option  of  setting  separate  threshold  values  for  which  neither 
S/U  measures  nor  technological  complexity  scores  may  exceed  during  a 
clustering  process.  Thus,  technological  complexity  can  be  used  as  a  criterion 
score  in  much  the  same  way  as  can  be  a  maximum  S/U  measure  value,  the  maximum 
workload  total  hours,  and  a  maximum  School  and  MOS  Boundary  Violation  score. 
This  Is  in  contrast  to  the  use  of  the  S/U  gain  score  as  an  objective  function 
for  determining  "best"  pairs  for  trial  merger  at  each  Iteration  of  the 
aggregation  process. 

The  metric  for  the  technological  complexity  variable  Is  considerably 
Inferior  to  the  metric  of  the  S/U  measure.  With  care,  a  good  ordinal  scale 
can  be  created  so  that  the  sum  of  the  D/C  scores  can  provide  a  basis  for 
saying  that  composites  having  a  higher  value  for  one  sum  of  scores  has  a 
greater  degree  of  technological  complexity  than  a  composite  yielding  a  smaller 
sum  of  such  scores.  However  a  difference  score,  of  the  type  used  to  compute 
the  S/U  gain  score,  could  not  be  trusted  to  be  comparable  at  the  high  and  low 
ends  of  the  scale.  Thus,  the  metric  for  the  technological  complexity  score 
does  not  meet  the  desired  standard  for  an  objective  function  scale.  Neither 
does  this  variable  have  a  sufficient  face  valid  relationship  to  an  underlying 
utility  function  to  justify  its  use  as  an  objective  function,  although  Its 
relationship  to  one  facet  of  a  credible  utility  function  (qualitative  manpower 
requirements)  is  adequate  to  justify  its  use  as  a  threshold  criterion 
variable. 
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Opportunities  for  Job  Engineering.  When  jobs  identified  by  Product  Five 
appear  to  be  either  uniformly  too  high  or  uneven  with  respect  to  technological 
complexity,  the  analyst  may  wish  to  lower  the  criterion  threshold  value 
previously  assigned  to  the  technological  complexity  variable,  while  adjusting 
other  parameter  values  (e.g.  for  the  minimum  S/U  gain  score)  to  force  more 
consideration  of  technological  complexity  in  the  clustering  process.  Most  of 
the  traditional  goals  of  job  engineering  are  obtainable  through  the 
appropriate  manipulation  of  threshold  values  for  criterion  variables  and/or 
the  careful  relaxation  of  the  constraints  that  produce  the  0/1  matrix. 

POSSIBLE  EXPANS I OH  CAPABILITIES 


Funding  availability  for  Product  Five  is  likely  to  permit  level  1 
development  only.  Consideration  of  training  transfer  effects,  teaming  decoy 
rate,  and  importance  weighting  would  be  considered  for  developmental  levels  2 
or  3  (see  Table  1  above).  The  following  discussion  on  each  of  these  expansion 
capabilities  is  only  for  information  and  general  consideration  at  this  point. 

TRAINING  TRANSFER 

The  process  of  tabulating  the  reduction  of  training  costs  that  can  be 
accrued  as  a  result  of  merging  two  job  components  should  consider  all  training 
requirements  that  are  common  to  two  or  more  of  the  tasks  eligible  for  merger. 
By  this  reasoning,  the  training  needed  to  acquire  all  types  of  skills  or 
knowledges  not  unique  to  a  single  task  should  be  candidates  for  inclusion  as 
components  of  a  S/U  measure. 

The  skills  and  knowledge  not  unique  to  a  task  fall  into  categories  with 
radically  different  implication  for  the  computational  mechanics  involved  in 
assuring  their  appropriate  contribution  to  the  S/U  measure.  Those  skills  and 
knowledges,  both  elementary  and  advanced,  that  are,  in  their  entirety, 
prerequisite  for  the  learning  of  more  specific  task  skills,  are  easily  dealt 
with  as  "competencies"  with  rules  for  concatenating  sets  of  competencies 
across  components  as  they  are  merged.  However  other  tasks  with  sufficient 
similarity  to  other  tasks  as  to  make  it  intuitively  obvious  that  the 
capability  to  perform  one  such  task  reduces  on-the-job  training  requirements 
for  the  others  requires  a  different  computational  treatment.  The  skills  in 
this  category  provide  the  basis  for  some  tasks  affecting  others  through 
"training  transfer  effect".  It  is  intuitively  credible  that  the  commonality 
of  such  skills  provides  a  high  probability  that  an  incumbent  who  can  do  well 
on  one  task  will  also  be  able  to  perform  well  on  other  tasks  having  a  high 
commonality  of  such  skills. 

The  benefits  accrued  from  training  transfer  effects  (expressed  as 
training  hours)  when  two  job  components  are  merged  have  an  effect  which  is  of 
the  same  sign  as  the  S/U  value  different  score  that,  when  multiplied  by  (-1), 
provides  the  S/U  gain  score.  Thus,  both  the  S/U  gain  and  the  D/C  gain  are 
obtained  by  subtracting  the  score  associated  with  the  concatenated  categories 
(competencies  in  the  one  case  and  C/Ds  in  the  other)  of  the  merged  job 
component  from  the  sum  of  the  training  hours  associated  with  the  categories 
required  by  the  two  constituant  job  components.  The  negative  sign  of  both 
these  effects  are  conceptually  correct  since  they  are,  in  theory,  being 
subtracted  from  a  large  total  number  of  training  hours  (a  total  that  is  not 
needed  for  the  aggregation  algorithms,  and  is  unknown).  The  two  effects  (the 
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S/U  gain  score  obtained  from  considering  competencies  and  the  D/C  gain  score) 
will  be  added  together  and  multiplied  by  (-1)  to  form  the  S/U  gain  score  (at 
developmental  level  2). 

A  means  of  expressing  the  transfer  effects  in  terms  of  a  metric  which, 
like  that  used  for  competencies,  can  adequately  reflect  the  effects  of  merging 
one  cluster  of  tasks  with  another  cluster  without  requiring  the  analyst  to 
re-estimate  transfer  effects  during  the  aggregation  process  is  required. 
Also,  since  the  transfer  effects  due  to  similarity  of  tasks  is  being  added  to 
the  gain  effected  by  concatenating  competencies,  a  compatible  metric  for  the 
two  is  essential.  Thus  it  was  decided  to  express  training  transfer  effects  in 
terms  of  training  hours  saved  as  a  consequence  of  a  similarity  expressable  as 
a  communal ity  of  each  such  task  with  a  generic  task  that  contains  a  set  of 
general  features  included  in  a  group  of  tasks. 

The  use  of  the  concept  of  generic  tasks  could  be  avoided  by  requiring  the 
analyst  to  make  pair  wise  comparisons  of  all  eligible  tasks  to  estimate:  (1) 
the  overlap  across  each  pair  of  tasks  and  (2)  the  uniqueness  of  each  task 
(that  part  of  the  task  that  would  provide  training  transfer  effects  to  no 
other  task  in  the  set  being  evaluated.  This  approach  would  be  more  expensive 
of  the  analyst's  time  than  the  identification  and  use  of  generic  tasks  to 
accomplish  a  similar  purpose.  Also,  the  extension  of  pairwise  comparisons  to 
triples,  quadruples,  etc.,  with  a  mathematical  deletion  of  overlap  to  achieve 
something  comparable  to  set  concatenation  would  require  at  least  as  many  (and 
possibly  more)  assumptions  about  the  distributions  of  the  overlapping 
(duplicate)  elements  than  is  required  in  the  proposed  generic  task  approach. 

The  Proposed  Approach.  This  approach  calls  for  the  analyst  to  identify 
common  features  across  tasks  and  to  organize  these  features,  with  the 
assistance  of  a  Product  5  decision  aid,  into  the  format  of  a  generic  task. 
The  number  of  hours  required  to  accomplish  mastery  of  the  generic  task  is 
estimated  by  comparison  with  competencies  in  the  data  bank  file  possessing 
comparable  descriptions  and/or  otherwise  considered  by  the  analyst  to  have 
similarities  along  relevant  dimensions.  This  training  transfer  effect  for  a 
generic  task  expressed  in  training  hours  will  be  referred  to  as  "TTH". 

The  TTH  values  are  estimated  for  each  generic  task  independent  of  the 
special  characteristics  of  each  task  related  to  that  generic  task.  Next,  the 
analyst  will  consider  each  task  on  an  individual  basis  and  estimate  both:  (1) 
the  maximum  training  transfer  effect  each  generic  task  could  have  on  that 
task— assuming  all  other  tasks  related  to  the  generic  task  have  been  mastered, 
and  (2)  the  training  transfer  effect  that  would  be  expected  from  the  mastery 
of  only  one  other  task.  The  "other"  task  would  be  defined  as  one  of  an 
average  degree  of  similarity— with  respect  to  the  features  of  the  generic  task 
held  in  common.  These  two  effects  will  be  estimated  as  percentages  of  the  TTH 
associated  with  each  generic  task  that  could  be  saved  under  the  two  conditions 
(a  maximum  and  the  effect  of  only  one  other  task)  for  each  specific  task. 
These  two  values  will  be  referred  to  as  Pmgt  and  respectively  for  a 
specific  generic-task  and  system  task. 

When  there  are  several  generic  tasks  that  relate  to  a  given  task  the 
analyst  will  have  the  option  of  estimating  the  percent  of  the  required 
training  time  for  a  task  that  is  unique  to  that  task  (Pu)  and  the  percent  (Pc) 
that  is  potentially  made  unnecessary  as  the  consequence  of  the  mastery  of  all 
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other  tasks.  Pu  Is  analogous  to  the  unique  factor  variance  and  Pc  to  the 
common  factor  variance  in  the  factor  analysis  (Pu=l-Pc).  The  Pc  for  a  task 
provides  the  upper  limit  of  transfer  effects  from  all  sources  on  that 
particular  task.  In  every  case  Pc  Pmgt  Pigt* 

The  Algorithm.  When  a  sufficient  number  of  tasks  which  Incorporate  a 
particular  generic  task  have  been  clustered  Into  a  job  component,  the  transfer 
training  effort  for  a  specific  generic  task  will  be  considered  equal  to  Pmgt 
times  "TTH"  (see  the  first  paragraph  of  this  section).  The  effects  of  having 
just  one  pair  of  such  similar  tasks  In  a  cluster  will  result  in  a  smaller, 
proportional  number  of  hours,  computed  as  Pigt  times  TTH. 

The  training  effects  for  one  task  and  one  generic  task  when  In  a  cluster 
of  n  similar  tasks  Incorporating  that  generic  task  can  be  expressed  by  the 
simply  stated  algorithm  provided  below.. 

Iterate  from  1=1  to  i=n  to  compute  task  multiplier  of  TTH  for  one  generic 
task— this  multiplier  will  be  (multipller)n  at  the  conclusion  of  the  following 
literature  process: 

(multipl1er)o=0; 

(multipl1er)i=(l-(mult1pl1er)1.1/Pmgt)times  (Pigt) i 

The  same  final  result  for  (multiplier),,  will  be  obtained  regardless  of 
the  order  in  which  the  n-1  other  tasks  are  entered  into  the  iterative  process 
of  the  above  algorithm.  This  multiplier  can  be  seen  to  be  equal  to  the  value 
of  Pigt  for  the  other  task  when  there  is  only  1  pair  of  tasks  in  the  cluster 
and  will  approach  but  not  quite  equal  the  value  of  Pmgt  when  the  cluster  size 
Is  large  and/or  the  differences  between  Pmgt  and  P^  are  small.  An  example 
of  values  for  several  examples  of  clusters  are  provided  in  Figure  15. 

The  algorithm  above  is  based  on  the  assumption  that  training  transfer 
will  behave  as  if  the  effect  was  due  to  overlapping  elements  which  are  spread 
evenly  over  the  maximum  area  of  overlap  (represented  by  Pmgt).  Each  new  task 
brought  into  a  cluster  brings  in  additional  elements,  some  of  which  correspond 
to  elements  already  counted  as  being  held  in  common  with  at  least  one  other 
task.  Such  duplicate  elements  must  not  be  allowed  to  increase  the  size  of  the 
common  area,  but  must  Instead  be  deleted  from  consideration.  Only  those  new 
elements  that  fall  Into  the  as  yet  unexplained  portion  of  the  area  identified 
by  pmgt  should  be  allowed  to  Increase  the  common  area.  This  common  area, 
expressed  as  a  percentage  of  the  training  transfer  effect  of  a  specific 
generic  task  is  the  variable  Identified  as  (multiplier)-j  in  the  above 
algorithm. 

The  job  component  training  transfer  score  is  computed  as  the  sum  of  the 
task  TTH  scores  for  all  constltuant  tasks.  Each  task  score  contributing  to 
this  sum  may  be  computed  as  the  smaller  of  two  alternative  values:  (1)  the  sum 
of  TTH  scores  across  all  generic  tasks  (for  which  an  algorithm  provided  above) 
or  (2)  the  largest  TTH  associated  with  a  task  times  Pc. 

Training  Transfer  Effect  as  a  Component  of  the  S/U  Measure.  When  job 
components  are  merged  the  competency  sets  for  the  two  constituant  components 
are  concatenated  to  form  a  new  set  with  no  duplicates  for  the  merged  job 
component.  A  similar  concatenation  operation  is  performed  on  D/Cs  during  the 
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Three  Computational  Examples 
(For  the  Multiplier*  That  is  Applied 
To  Training  Hours  for  a  Generic  Task) 


Unique 


Example 

i 

Plgt 

multiplier^ 

Proportion 

Process** 

1 

0 

0 

1 

1 

.20 

.20 

1.0 

(1-0/40). 20+0 

1 

2 

.15 

.275 

.5 

(1-.20/.40) . 15+.20 

1 

3 

.10 

.30625 

.3125 

(1-.275/.40) . 10+.275 

2 

0 

_ 

0 

_ 

2 

1 

.10 

.10 

1.0 

(1-0/. 40). 10+0 

2 

2 

.15 

.2125 

.75 

(1-. 10/.40) . 15+. 10 

2 

3 

.20 

.30625 

.46875 

(1-. 2125/. 40). 20+. 2125 

3 

0 

0 

• 

3 

1 

.20 

.20 

1.0 

(1-0/. 40). 20+0 

3 

2 

.20 

.30 

.5 

( 1- . 20/ . 40 ) . 20+ . 20 

3 

3 

.20 

.35 

.25 

(1-.30/.40) .20+. 30 

3 

4 

.20 

.3750 

.125 

(1-.35/.40) .20+. 35 

3 

5 

.20 

.3875 

.0625 

(1-. 3750/. 40). 20+. 3750 

*The  training 

transfer 

effect  of 

a  generic  task 

on  a  task  (as  a  result  of 

being  in  a  cluster  of  n  tasks  related  to  the  generic  task)  is  expressed  as  the 
number  of  training  hours  required  for  the  generic  task  times  (multipl ier)n. 
The  training  transfer  effect  due  to  one  generic  task,  for  a  cluster  of  n  such 
tasks,  is  the  sum  of  n  such  values. 

**This  process  is  expressed  by  the  following  iterative  algorithm: 

(multipl ier)0=  0;  Pmgt  =  .40; 

(multiplier)^  (l-(multipl ier) i _ i/Pmgt ) p igt  (multiplier)^ 

See  text  for  definitions  of  P^g^  and  Pmgt 


FIGURE  15.  Three  Computational  Examples 
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recomputation  of  technology  complexity  upon  the  merger  of  two  job  components. 
In  contrast,  the  training  transfer  effect  score  for  a  candidate  merger  must  be 
recomputed  from  task  data;  there  Is  no  concept  of  sets  of  generic  tasks  that 
can  be  concatenated  to  represent  a  set  resulting  from  a  merger.  Nor  can  the 
training  transfer  effect  scores  of  two  constltuant  job  components  be  summed  to 
obtain  the  score  resulting  from  a  merger.  Instead  the  scores  for  the  tasks  In 
the  merged  job  component  must  be  recomputed  using  the  new  value  for  n  In  to 
compute  a  value  for  (multlpller)n  for  each  task  and  generic  task  in  the  new 
cluster.  Fortunately  this  recomputation  must  be  accomplished  for  only  one  row 
of  the  training  transfer  score  matrix  during  each  iteration,  and  for  each  task 
already  in  a  cluster  the  value  of  (multiplier),,.^  is  already  known. 


LEARNING  DECAY  RATE 

The  required  number  of  training  maintenance  hours  associated  with  a 
competency  can  be  expressed  as  a  product  of  how  often  (frequency)  such 
training  occurs  and  the  number  of  training  hours  in  each  session  (duration). 
Obviously  duration  and  frequency  can  be  traded  off  for  any  given  competency. 
The  shorter  and  less  complete  the  training  maintenance  sessions  the  more 
frequently  one  can  expect  to  need  such  a  session.  However,  one  can  expect 
experts  to  agree  to  a  considerable  extent  on  differences  in  "best"  durations 
and  needed  training  frequencies  under  the  condition  of  zero  performance 
frequency— across  a  sample  of  the  population  of  competencies. 

The  probable  frequency  with  which  maintenance  training  is  needed  for  each 
competency  is  a  function  of  the  learning  decay  rate  for  that  competency  and 
the  frequency  with  which  the  competency  Is  practiced  on  the  job  (performance 
frequency).  The  latter  Is  a  function  of  which  tasks  are  Included  In  a  job 
and.  If  frequency  of  performance  is  adequately  estimated  for  the  purpose  of 
generating  workload  figures.  Is  also  available  for  Inclusion  In  algorithms 
used  to  estimate  training  maintenance  requirements.  A  greater  performance 
frequency  can  compensate  for  a  high  learning  decay  rate,  and  a  sufficiently 
high  performance  frequency  can  reduce  the  training  frequency  requirement  to 
zero,  Irregardless  of  how  high  the  training  decay  rate  might  be.  The  advantage 
In  aggregating  tasks  with  low  performance  frequency  for  a  number  of  high  cost 
competencies  into  a  job  composite  already  possessing  a  high  performance 
frequency  for  those  competencies  is  intuitively  obvious.  The  proposed 
aggregation  process  for  developmental  level  3  is  consistent  with  this 
Intuition. 

Data  on  learning  decay  would  be  obtained  In  terms  of  how  long  a  soldier 
could  go  without  a  refresher  training  session  under  the  condition  of  zero 
performance  frequency.  NC0,s  at  Schools  and  on-the-job  locations  could  base 
such  a  judgement  on  actual  experience  with  soldiers  who  have  needed  refresher 
training.  Such  expert  judgements  could  be  compared  with  learning  decay 
findings  In  the  literature.  Their  findings  could  could  be  used  to  define 
rules  for  estimating  learning  decay  rate  which,  if  shown  to  have  construct 
validity,  be  used  to  generate  learning  decay  rate  estimates  for  Schools  whose 
subject  matter  experts  are  not  available. 
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IMPORTANCE  WEIGHTING— ADVANTAGES  AND  DISADVANTAGES 


Maximizing  the  Relationship  of  the  S/U  Measure  to  the  Underlying  Utility 
Function.  If  given  the  choice  between  placing  a  task  in  a  cluster  where  its 
Inclusion  would  add  nothing  to  the  training  hours  required  to  perform  the  job 
vs.  placing  it  in  an  alternative  cluster  where  the  probability  the  new  task 
can  be  performed  well  by  all  incumbents  who  can  perform  the  other  tasks  well. 
Army  managers  would  probably  choose  the  latter.  Fortunately  the  two  criteria 
are  very  likely  to  be  highly  correlated,  and  the  making  of  clustering 
decisions  to  maximize  the  first  benefit  will  probably  obtain  most  of  the 
benefits  obtainable  from  directly  seeking  the  alternative  goal.  This 
correlation  between  these  two  criteria  should  be  even  higher  If  training  hours 
associated  with  a  competency  were  multiplied  by  a  weight  that  reflected  the 
relationship  of  the  competency  to  the  ability  of  a  soldier  to  accomplish  task 
objectives.  Such  weights  are  referred  to  In  this  report  as  "Importance 
weights". 

The  Metric.  It  is  important  that  training  hours  weighted  by  Importance 
weights  should  still  express  training  hours  required  to  accomplish  some 
objective.  With  the  application  of  the  weights,  that  objective  changes  from 
one  of  being  proficient  in  a  required  competency  to  that  of  being  able  to 
accomplish  task  standards.  The  concept  of  the  desirability  of  overtraining  on 
the  more  essential  competencies  set  at  expense  of  undertraining  on  less 
essential  competencies  is  Introduced.  Weights  can  be  selected  and  applied 
which  for  a  given  task  leave  the  sum  of  the  weighted  training  hours  for  all 
competencies  associated  with  a  task  equal  to  the  unweighted  sum. 

The  Analyst's  Estimate.  The  analyst  will  be  assisted  by  a  decision  aid 
in  the  grouping  of  competencies  into  importance  categories  for  each  task.  The 
analyst  would  then  Indicate  approximate  percentages  of  overtraining  and 
undertraining  that  best  reflects  his  estimate  of  each  categories' Importance  to 
the  accomplishment  of  task  objectives.  The  decision  aid  logic  will  compute 
weights,  reflecting  (as  much  as  possible)  the  analyst's  decisions,  which  will 
yield  the  same  total  number  of  training  hours  for  the  sum  of  weighted 
competencies  as  for  the  sum  of  unweighted  competencies. 

The  Role  of  Importance  Weights  In  Computing  the  S/U  Measure.  To  compute 
the  S/U  measure  for  a  newly  merged  job  component,  the  weights  for  each 
competency  will  be  averaged  across  tasks  and  then  applied  to  each  competency. 
This  is  algebraically  equivalent  to  averaging  the  weighted  competencies  in  the 
following  manner: 

Average  weighted  competence  = 

Sum  from  1  to  m  (sum  from  j  to  m-j  ( 1/L j ) W^ j  Hj 

—where  n  is  the  number  of  tasks  In  the  cluster,  and  mi  is  the  number  of 
competencies  In  associated  with  the  ith  task,  Lj  is  the  number  of  tasks  which 
require  the  jth  competency,  W^j  Is  the  importance  weight  for  the  jth 
competency  In  the  1th  task  and  Hj  Is  the  number  of  training  hours  associated 
with  the  jth  competency.  If  all  w^j  are  equal  to  one  this  algorithm  would  be 
equivalent  to  concatenating  the  setsof  competencies  associated  with  each  task 
and  then  summing  the  training  hours  associated  with  the  concatenated  set. 
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ACCEPTABILITY,  USABIITY  AND  USER  WORKLOAD 


By  assigning  selected  functions  of  Product  Five  to  the  analyst,  a  minimum 
cost  product  containing  only  four  modules  will  be  designed.  This  minimum  cost 
system,  requires  the  analyst  to  designate  task  membership  in  jobs  (as  part  of 
the  last  module).  The  following  four  modules  would  comprise  this  system:  (1) 
Task  Identification,  (2)  Task  Data  Generation,  (3)  WorkLoad  Data  Generation, 
and  (4)  Manpower  and  Personnel  Requirements.  In  this  system,  the  first  module 
would  require  the  analyst  to  select  the  baseline  system(s)  with  no  more 
assistance,  than  is  provided  by  MIST  but  would  otherwise  remain  as  in  the 
complete  Product  Five  system.  The  second  module  would  involve  a  greatly 
reduced  effort  by  the  analyst;  the  third  module  would  require  more  analyst 
effort;  and  the  last  module  would  require  much  more  effort  and  more  difficult 
analyst  judgements. 

With  additional  cost,  additional  capabilities  could  be  successively  added 
to  this  minimum  Product  Five.  A  hierarchy  of  such  product  designs,  each  more 
costly  than  the  preceeding  one  of  lesser  complexity  and  capability,  could  be 
provided  to  meet  a  variety  of  cost  figures  in  accordance  with  the  "design  to 
cost"  philosophy. 

A  HIERARCHY  OF  DESIGN 


The  first  step  upward  from  the  minimum  cost  system  should  include  the 
addition  of  a  combined  duty  module  and  position  generation  module  consisting 
of  the  0/1  constraint  matrix  and  supporting  decision  aids.  No  data  bank  would 
be  required  for  this  economical  design.  The  merging  of  job  component  pairs 
could  be  accomplished  by  considering  only  connectivity  and  the  0/1  constraints 
on  task  mergers,  tested  each  time  by  a  workload  threshold  set  by  the  analyst. 
The  effort  required  of  the  analyst  in  the  task  data  generation  module  would 
increase  since  he  must  create  the  0/1  matrix  from  his  information  regarding 
the  system,  and  any  other  relevant  information  pertaining  to  the  proposed 
implementation. 

The  second  step  upward,  to  obtain  a  definite  increase  in  capability  at 
minimum  cost,  should  include  the  consideration  of  the  S/U  clustering  algorithm 
in  the  task  aggregation  model  for  both  a  duty  module  generation  module  and  a 
duty  position  generation  module.  Only  one  data  bank  file,  the  competency 
file,  would  be  added  as  part  of  this  design  increment. 

The  third  step  upward  should  include  the  addition  of  the  other  three  data 
banks  and  the  other  three  modules.  The  system  would  then  include  all  the 
modules  at  the  S/U  development  of  level  1. 

The  fourth  and  fifth  steps  upward  in  cost  and  capability  should 
correspond  to  S/U  developmental  levels  2  and  3  respectively. 


THE  EXPANDABILITY  CAPABILITY 

It  was  noted  earlier  that  the  cost  of  adding  additional  features  later 
was  not  much  more  than  the  cost  of  providing  these  features  initially  in  the 
product;  this  was  said  with  specific  reference  to  the  features  required  to 
expand  from  developmental  level  I  to  developmental  2  and  3.  This  is  partly 
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true  because  the  data  bank  shell  and  most  of  the  user  Interface  software  would 
already  be  in  place  at  the  completion  of  level  1  development.  However,  for 
the  most  part,  this  expandability  capability  must  be  deliberately  designed 
Into  the  product  as  proposed  by  the  Perceptronics  and  HSI  research  team. 

Not  so  much  of  the  overall  structure  of  Product  Five  development  level  1 
(step  3  in  the  hierarchy  described  above)  is  present  in  the  minimum  cost  or 
step  1  design.  The  overall  structure  of  the  product  as  present  in  the  3rd, 
4th,  and  5th  step  designs  first  becomes  recognizable  in  the  2nd  step  design. 

A  design-to-cost  strategy  that  provided  for  the  construction  of  a  product 
at  either  the  2nd  or  3rd  steps  of  cost  and  capability  is  a  practical 
alternative  that  should  be  considered.  The  cost  and  benefits  that  could  be 
expected  from  each  successive  expansion  could  then  be  determined  with  greater 
certainty. 


DETERMINATION  OF  SCHOOL  AND  MOS  BOUNDARIES 

Army  personnel  managers  resist  the  proliferation  of  MOS's  and  of  special 
assignment  categories  within  MOS  that  might  come  about  if  the  MOS  structure 
were  altered  each  time  It  appears  that  a  newly  Introduced  system  has  different 
requirements  for:  (1)  soldier  characteristics,  (2)  training,  or  (3)  career 
progression  than  the  most  similar  existing  MOS.  Similarly,  Army  schools 
hesitate  to  introduce  new  courses  when  they  suspect  that  a  small  addition  to 
an  existing  course  and/or  a  heavy  reliance  on  on-the-job  training  can  meet 
minimum  requirements.  Thus  the  creation  of  jobs  that  cut  across  MOS  and/or 
school  boundaries  run  more  than  just  the  risk  that  the  cost  of  providing  the 
new  MOS  and  new  school  courses  will  be  charged  to  the  development  system. 
There  Is  a  real  risk  that  the  new  job  will  be  laid  on  a  Procrustian  bed  and 
made  to  fit  the  existing  system,  regardless  of  the  cost  to  system  performance. 

The  Manpower  and  Personnel  Requirements  as  estimated  by  Product  Five  will 
be  more  valid  if  the  jobs  used  for  making  estimates  of  workload  and  number  of 
required  jobs  are  very  close  to  the  duty  positions  that  will  eventually  be 
placed  on  TO&E's  and  TDA's  for  the  fielding  of  the  system. 

One  must  carefully  consider  the  need  for  a  model  to  detect  tasks  that 
either:  (1)  lie  on  MOS  or  school  boundaries  or  (2)  lie  on  the  opposite  side 
of  such  a  boundary  as  compared  to  other  relevant  tasks— tasks  that  the 
aggregation  model  will  place  in  the  same  job  when  the  boundary  consideration 
option  is  not  used.  If  this  detection  can  be  readily  accomplished  by  the 
analyst  using  existing  resources  outside  of  Product  Five,  the  analyst  can  also 
be  presumed  capable  of  assigning  boundary  violation  scores  to  each  task.  If 
the  analyst  has  these  capabilities,  the  cost  of  creating  a  data  bank  file  and 
a  decision  model  can  be  avoided.  The  option  for  the  data  bank  file  and 
decision  model  has  been  Included  in  the  proposed  design  based  on  the  belief 
that  many  analysts  will  not  In  themselves  be  sufficiently  expert  In  Army 
personnel  and  training  systems  to  allow  them  to  make  the  independent 
judgements  otherwise  required. 

The  content  of  the  MOS  and  School  Boundaries  file  will  be  drawn  from  the 
content  of  the  other  data  bank  files,  and  the  descriptors  will  include  those 
used  for  the  competency  file,  the  Baseline  Systems  file,  and  the  D/C  file. 
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The  difference  between  those  other  data  bank  files  and  this  data  bank  file 
lies  in  its  additional  descriptors  (e.g.,  D/Cs  and  competencies)  and  its 
structure. 

The  HOS  and  School  Boundary  File  will  have  relatively  small  records 
containing  primarily  MOS  and  School  Identification  data  but  will  have  more 
descriptors  and  multiple  links  between  de  criptors  and  the  file  records.  A 
file  search  by  the  decision  model  will  yield  the  distribution  of  descriptor 
links  to  each  MOS  and  school  relevant  to  the  set  of  descriptors  entered  from 
the  task  data  working  file. 

The  distribution  of  descriptor  links  to  each  MOS  and  school  will  be 
analyzed  by  the  decision  model  on  a  task-by-task  basis  to  determine  whether  a 
single  primary  membership  in  a  MOS  or  school  domain  exists.  Where  such  a 
primary  membership  exists,  links  to  other  domains  that  duplicate  the 
descriptors  linked  to  the  primary  domain  will  be  deleted  and  the  remaining 
links  analyzed  to  see  If  a  significant  linkage  to  other  domains  remains. 
These  "significant"  links  will  then  be  scored  to  yield  a  boundary  violation 
score  for  the  task. 

Tasks  for  which  two  or  more  primary  memberships  in  MOS  or  school  domains 
exist  will  be  analyzed  separately  with  respect  to  each  domain.  The 
computation  of  a  boundary  violation  score  requires  the  selection  of  one  of 
those  multiple  domains  as  relevant  to  the  cluster  to  which  the  task  has  been 
assigned;  all  non-dupl icative  links  to  other  domains  are  counted  as  boundary 
violations. 


DESI6H  AND  DEVELOPMENT  OF  DATA  BASE  FILES 

The  data  base  files  utilized  in  the  proposed  Product  Five  have  been 
included  because  their  presence  will  provide  the  following  benefits: 

(1)  The  analyst  can  readily  draw  upon  Army  doctrine  and  the  judgements 
of  a  variety  of  experts  without  having  to  select,  locate  and  prevail 
upon  such  experts  to  render  judgements  during  the  process  of  each 
analysis. 

(2)  The  quality  of  this  Information  acquired  systematically  for  the  data 
bank  should  exceed  the  quality  of  the  information  the  analyst  could 
obtain  through  his  own  efforts. 

(3)  The  cost  of  obtaining  the  information  for  the  data  banks  will  be 
less  than  the  cost  of  having  a  number  of  analysts  obtaining  the 
required  Information,  on  their  own,  to  analyze  all  relevant  systems 
over  a  three  year  period  of  time. 

(4)  Information  obtainable  from  a  data  bank  file  reduces  the  burden  on 
the  analyst  of  providing  Input  to  analysis  models. 

(5)  The  availability  of  information  in  the  appropriate  format  makes  an 
objective  and  systematic  analysis  possible,  with  complete 
documentation  and  repeatability  of  that  analysis  assured. 
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The  data  base  consists  of  four  special  purpose  information  files  and  a 
shell  which  assures  that  those  files  are  available  to  the  models  and  decision 
aids  that  require  access  to  these  files.  The  shell  provides  for  direct  access 
to  these  files,  and  provides  for  direct  access  by  the  analyst  for  content 
additions,  direct  queries,  and  other  purposes.  The  shell  will  also  provide 
such  interfaces  to  the  user  as  menus  and  helps  in  the  direct  use  of  the  data 
bank. 


I/O  RELATIONSHIPS  WITH  PRODUCT  SIX 

Jobs,  in  terms  of  their  constituent  tasks,  and  the  workload  for  those 
jobs  for  the  system(s)  being  evaluated  will  be  provided  as  output  to  a  working 
file  that  can  easily  be  used  as  input  to  Product  Six.  The  number  of  jobs 
associated  with  specified  system  deployment  figures,  and  the  total  Army  wide 
manpower  implication,  by  job,  will  also  be  recorded. 

As  useful  for  Product  Six  analyses  or  for  reference  by  the  analyst  in 
establishing  Product  Six  options  and  parameters,  duty  modules  can  be  provided 
on  the  working  file  for  Product  Six  use.  As  with  jobs,  the  duty  modules  are 
Identified  in  terms  of  their  constituent  tasks  and  by  the  jobs  of  which  they 
are  a  component.  Workload,  and  criterion  variable  values  (S/U  measure, 
technology  complexity  score,  and  both  School  and  MOS  membership  information 
and  School  and  MOS  boundary  violation  scores)  can  also  be  provided.  All 
Information  in  both  the  working  files  (particularly  the  task  0/1  constraint 
matrix),  and  the  data  bank  files  of  Product  Five  would  be  useful  to  the 
analyst  for  both  setting  up  Product  Six  and  for  Interpreting  Product  Six 
results. 


Product  Five  Iterations  in  Response  to  Product  Six  Results.  Soldier 
characteristics  data  on  the  jobs  produced  in  Product  Five  may  indicate  where 
further  job  engineering  should  be  accomplished  (e.g.,  to  reduce  the  number  of 
jobs  with  a  high  cognitive  loading).  To  the  extent  that  such  Product  Six 
results  can  be  attributed  to  specific  tasks,  these  high  driver  tasks  can  be 
identified  as  kernels  of  duty  modules  that  will  be  more  homogeneous  with 
respect  to  required  soldier  characteristics.  This  can  be  accomplished  through 
the  modification  of  the  0/1  constraint  matrix  and  then  proceeding  once  more 
through  the  aggregation  process. 

It  should  be  noted  that  the  cognitive  loading  of  tasks  in  a  duty  module 
could  be  high  although  the  technology  complexity  score  is  relatively  low--if 
the  technology  requirement  Is  highly  focuses  with  only  one  of  a  very  few  high 
technologies  required.  Product  Five  provides  the  means  of  controlling  the 
span  of  technology  requirements  but  requires  feedback  from  Product  Six  to 
control  the  level  of  the  requirement. 

Use  of  Product  Six  cognitive  loading  data  as  a  fourth  criteria  variable: 
It  would  be  relatively  easy  to  design  product  Five  to  provide  the  analyst  the 
option  of  setting  upper  and  lower  threshold  values  on  a  Cognitive  Loading 
Variable.  The  computed  values  of  the  Cognitive  Loading  Variable  for  each  task 
to  be  compared  to  the  thresholds  would  be  obtainable  from  Product  Six. 
However,  such  a  variable  would  have  to  be  used  In  a  different  fashion  than  the 
other  three  criterion  variables.  The  other  three  are  used  with  a  logic  that 
tests  the  upper  limit  permissable  for  those  criterion  variables  in  a  cluster. 
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The  lower  limit  for  cognitive  loading  values  would  be  at  least  as  Important  in 
testing  for  acceptability  of  two  job  components  for  inclusion  in  a  merged 
component.  Thus  an  acceptable  range,  rather  than  a  single  threshold  value, 
would  have  to  be  tested  to  determine  whether  a  merger  is  consistent  with  the 
job  engineering  goal  of  reducing  the  number  of  jobs  having  a  high  cognitive 
loading. 

Use  of  Product  Six  cognitive  loading  data  as  task  similarity  measures: 
Task  Cognitive  Loading  (TCL)  values  from  Product  Six  could  be  substituted  for 
task  S/U  measure  values  for  use  In  the  aggregation  process  of  the  Product  Five 
clustering  algorithm.  A  more  traditional  clustering  approach  would  then 
become  appropriate.  The  goal  of  the  clustering  process  would  become  one  of 
maximizing  the  homogeneity  of  the  tasks  in  a  job  component  with  respect  to 
TCL.  A  process  analogous  to  a  discriminant  analys1s--1n  which  the  within 
cluster  variance  of  TCL  values  are  maximized  and  the  between  cluster  variance 
is  minimized— all  within  the  constraints  of  the  0/1  constraint  matrix,  would 
meet  the  engineering  objective  of  reducing  the  number  of  jobs  with  a  high 
cognitive  loading. 

The  provision  of  a  capability  of  clustering  on  TCL,  as  described  above, 
is  not  included  in  the  costing  for  this  concept  paper.  This  is  a  capability 
that  could  be  added  after  the  completion  of  Product  Six. 


THE  ZERO  LEVEL  OF  S/U  DEVELOPMENT— DEVELOPMENT  LEVEL  ZERO 

Proceeding  without  the  use  of  a  S/U  measure  and  when  the  0/1  constraint 
matrix  leaves  no  room  for  further  clustering  was  addressed.  It  is  believed 
that  the  tasks  for  some  systems,  particularly  the  operator  tasks,  will  be  so 
constrained  as  to  preclude  the  necessity  of  computing  S/U  measures.  Other 
systems  may  have  jobs  so  well  defined  by  predetermined  doctrine  that  most 
tasks  will  be  placed  immediately  in  strawman  jobs  with  only  a  very  few  tasks 
remaining  unassigned.  In  such  cases  the  analyst  may  still  wish  to  evaluate 
jobs  and  assigned  tasks  in  terms  of  the  three  criterion  variables— but 
completely  bypassing  the  aggregation  process  that  is  based  on  the  S/U  measure. 

For  the  strawman  option,  the  analyst  may  have  predefined  jobs  which  must 
contain  a  number  of  specified  tasks.  These  tasks  provide  a  kernel  for 
strawman  jobs  which  can  then  be  compared  with  "loose"  tasks.  Zeros  can  be 
placed  in  appropriate  cells  of  the  0/1  constraint  matrix  to  assure  that  two 
kernels  will  not  be  merged  with  each  other.  The  analyst  may  choose  to  assign 
the  "loose"  tasks  by  reference  to  the  criterion  variables,  again  without 
recourse  to  the  S/U  measures. 

The  optional  capability  of  clustering  tasks  from  the  0/1  constraint 
matrix  and  clustering  to  maximize  connectivity  was  also  addressed.  In 
addition  to  expressing  the  permissibility  of  merging  each  pair  of  tasks,  the 
0/1  constraint  matrix  contains  information  regarding  the  extent  to  which 
future  aggregation  options  are  foreclosed  if  two  tasks  are  merged.  For 
example,  two  tasks  for  which  a  merger  is  permissible  may  result  in  a  two-task 
job  component  which  can  be  merged  with  no  other  tasks— although  each  could  be 
merged  with  almost  half  of  the  other  tasks.  A  connectivity  index  for  this 
pair  would  be  very  low  and  would  indicate  the  undesirability  of  making  such  a 
merger.  A  measure  of  connectivity  for  each  pair  provides  a  good  estimate  of 
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how  many  other  tasks  remain  as  potential  members  of  a  cluster  Initiated  by 
merging  that  pair  of  tasks.  If  the  optimal  pair  for  merger  is  selected  on  the 
basis  of  its  high  connectivity  Index,  one  must  also  verify  that  the  selected 
pair  has  a  one  at  the  juncture  of  those  two  tasks  in  the  0/1  constraint 
matrix.  In  short,  connectivity,  computed  entirely  form  the  0/1  constraint 

matrix,  may  be  treated  as  the  objective  function,  but  the  constraints  recorded 
in  the  0/1  matrix  must  also  be  obeyed  in  selecting  pairs  for  merger. 

Computing  a  measure  of  connectivity  for  the  0/1  constraint  matrix  will  be 
referred  to  as  the  matrix  M.  The  squaring  of  this  matrix,  producing  M2, 
provides  a  matrix  in  which  the  element  In  the  ith  row  and  jth  column  provides 
the  number  of  tasks  that  could  be  contained  in  a  merged  task  consisting  of  the 
1th  and  jth  tasks.  This  powering  of  M  provides  us  with  a  good  measure  of  the 
connectivity  available  after  each  potential  merger  of  task  pairs. 

It  is  recommended  that  Product  Five  will  have  an  optional  capability  of 
clustering  job  components  to  maximize  connectivity.  Even  when  the  analyst 
chooses  to  use  the  aggregation  approach  that  utilizes  the  S/U  measure,  he  may 
choose  to  have  the  results  of  M2  displayed  to  him,  to  indicate  to  him  the 
extent  future  clustering  options  are  being  foreclosed  by  accepting  the  merger 
of  the  pair  yielding  the  best  S/U  measure. 

The  clustering  process  based  solely  on  the  maximization  of  connectivity 
while  complying  with  the  constraint  matrix  as  follows: 

(1)  Compute  M2,  retain  M 

(2)  Select  the  largest  cell  value  in  M2 

(3)  If  equivalent  cell  in  M  is  a  one  (otherwise  delete  cell  value  and 
repeat  step  2,  then  do  a  logical  add  of  the  two  rows  and  columns 
corresponding  to  the  selected  cell  (the  order  of  M  is  thus  reduced 
by  one). 

(4)  Defining  the  row  of  M  corresponding  to  the  newly  merged  tasks  as  V, 
compute  the  follow: 

V2=V!M 

(5)  Select  the  cell  with  the  largest  connectivity  value  considering  the 
cells  in  V2  and  all  cells  in  M2  except  those  in  the  rows  ad  columns 
corresponding  to  the  cell  previously  selected. 

(6)  Repeat  step  3  and  set  4 

(7)  Repeat  step  5  except  that  these  are  now  two  V2  vectors  to  consider 

(8)  continue  interation  until 

(a)  Connectivity  value  in  a  V2  vector  is  larger  than  any 
connectivity  value  In  M2,  or 

(b)  The  order  of  M  is  reduced  to  2. 

(9)  Select  largest  connectivity  value  In  the  set  of  V2  vectors,  and 
select  the  corresponding  task  pair  for  merger. 


TRAINING  OF  USERS 

This  section  presents  several  technical  ideas  that  are  viewed  as  logical 
outgrowths  of  the  "user-friendly"  front-end  for  the  conceptualized  system. 
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The  enhancements  presented  herein  focus  on  taking  advantage  of  the 
behavior  of  both  experienced  and  naive  users  as  they  Interact  with  the  "user 
friendly"  Interface  to  the  data  base.  When  a  uuer  addresses  a  particular 
logistics  or  forecasting  problem  using  the  system,  he  will  have  some  specific 
goal  In  mind.  He  will  then  try  to  use  the  system  in  a  number  of  different  ways 
to  achieve  that  goal.  The  overall  concept  here  is  to  capture  the  approaches 
that  the  user  employs  in  software,  and  to  build  a  "library"  of  user 
"protocols"  (ways  of  addressing  a  problem)  that  may  aid  a  subsequent  user  in 
solving  a  similar  (but  perhaps  not  Identical)  problem  In  the  future.  In  this 
way,  the  system  Is  expanded  so  as  to  become  a  more  useful  and  more  "friendly" 
tool  In  meeting  the  goal  for  embedded  training  In  the  forecasting  arena  In 
general.  We  believe  that  much  more  advantage  can  be  taken  of  the  computer 
In-the-loop  as  an  aiding  device  for  users  of  all  experience  levels  in 
achieving  the  ultimate  goal  of  accurate  and  rapid  forecasting. 

It  is  apparent,  from  the  nature  of  military  software  systems,  that  the 
burden  of  operating  the  system  and  making  It  do  what  the  user  wants  it  to  do 
Is  on  the  user  himself.  This  is  true  especially  for  systems  developed  without 
due  consideration  of  the  user's  behavior  patterns,  his  natural  tendencies  when 
performing  a  task,  of  patterns,  or  his  capability  to  absorb  the  meaning  of  the 
plethora  of  different  functions  and  commands  inherent  in  most  software 
packages.  The  solution  to  this  problem  has  been  to  spend  enough  time  at  the 
"front  end"  of  the  system  development  cycles  to  determine  exactly  what  the 
user  needs  from  the  system,  as  well  as  what  the  user  brings  with  him  to  the 
job  (e.g.,  knowledge,  experience,  tendencies,  etc.).  The  result  of  those 
development  efforts  that  have  dedicated  significant  amounts  of  time  to  front 
end  planning  has  been  a  better  user  Interface  for  the  products  of  those 
efforts,  so  that.  In  many  cases,  the  user  can  get  the  job  done  appropriately. 
However,  even  with  a  fairly  well-designed  user  Interface,  many  systems  still 
require  modules  or  components  that  supply  additional  aid  to  the  user.  Most 
common  of  these  "aids"  are  help  modes,  manuals,  walk-through  tutorials,  and 
often  costly  and  time-consuming  training  courses  or  curricula.  This  is 
especially  true  in  the  military  where  it  is  rare  to  see  a  software-based 
system  developed  that  does  not  require  extensive  training. 


PROTOCOL  FOLLOWING 


The  concept  of  protocol  following  involves  tracking,  in  software,  what  a 
user  does  as  he  interacts  with  a  computer-based  system.  In  the  current 
application  it  would  be  very  valuable  for  the  system  to  allow  the  user  to  go 
back  (after  task  performance)  and  investigate  the  procedures,  interactions,  or 
activities  he  engaged  in  that  produced  the  resulting  forecast,  whether  that 
result  was  desirable  or  not.  If  the  designer  wanted  to  include  that 
capability  in  the  system,  he  would  track  the  user's  keypresses,  screens 
accessed,  files  and  fields  viewed  and  selected,  and  other  components  of  the 
user's  "protocol",  and  store  them  in  the  system  for  access  and  review  later. 
Although  a  certain  amount  of  programming  and  user  interface  design 
(specifically  for  later  viewing  and  understanding  the  protocol)  would  be 
required  to  provide  this  capability,  the  concept  is  rather  simple  and 
straightforward,  and  is  certainly  a  workable  one. 
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QUASI-EXPERT  SYSTEM 

Although  It  enjoys  a  notable  reputation,  the  concept  of  an  expert  system 
appears  to  be  as  variable  as  the  range  of  Individuals  claiming  to  have  built 
one.  For  purposes  of  this  paper,  we  refer  to  the  component  of  the  system  we 
are  proposing  to  Implement  as  a  "quasi"  expert  system.  What  is  meant  by  this 
is  the  ability  of  the  system  to  generate,  upon  user  demand,  several 
alternative  ways  to  go  about  solving  a  problem.  Clearly,  the  alternatives 
would  have  to  be  matched  against  general  categories  of  problems.  Thus,  a 
taxonomy  of  problem  types  would  have  to  be  generated  based  on  what  we  know 
about  operations.  The  alternatives  developed  to  solve  these  types  of  problems 
would  be  based  on  the  protocols  that  could  be  captured  while  "experts"  are 
using  the  current  system  and  from  elicitation  from  experts  of  the  optimal 
strategies  for  addressing  and  solving  a  wider  range  of  problems. 

The  alternative  approaches  mentioned  above  can  be  considered  "expert 
models"  of  system  use  that  have  been  employed  previously  with  positive 
results.  In  general.  It  Is  clear  from  the  research  on  human  performance  that 
the  best  and  easiest  way  to  Increase  on  the  probability  that  an  individual 
will  perform  a  task  appropriately  is  to  provide  that  individual  with  a  model 
of  a  similar  task  previously  performed  successfully  by  someone  else  (or  even 
by  himself).  The  model,  in  essence,  serves  as  a  reference  for  the  user  that  is 
aimed  at  improving  productivity  as  measured  by  both  speed  and  accuracy  of 
performance  (Asiala,  1985). 

ADAPTIVE  TRAINING 


Of  the  many  types  of  training  approaches  in  the  literature,  adaptive 
training  Is  of  the  most  productive.  By  "adaptive"  is  meant  training  that 
conforms  to  the  trainee's  level  of  performance  at  any  given  time.  For 
example.  If  a  trainer  were  training  a  student  to  fly  a  plane,  the  training 
would  present  a  specific  problem  related  to  flight  and  would  observe  the 
trainee's  performance.  If  the  trainee  failed  to  perform  appropriately,  a  good 
trainer  would  attempt  to  restructure  the  problem  In  a  simpler  form,  perhaps 
omitting  a  more  difficult  component  temporarily  from  the  training  scenario. 
If  the  trainee's  performance  Improved,  the  trainer  would  then  increase  the 
difficulty  of  the  problem  (perhaps  by  reintroducing  the  difficult  component  he 
temporarily  removed)  and  observe  the  trainee's  performance.  In  this  way,  the 
amount  of  Information  presented  to  the  trainee  at  any  given  time,  or  the 
difficulty  of  the  problem  the  trainee  is  called  upon  to  address,  is  under  the 
trainer's  control,  and  Is  "adapted"  to  the  trainee's  current  level  of 
performance. 

LOGICAL  INTEGRATION  OF  THE  CONCEPTS 


We  believe,  then,  that  protocol  software  should  be  developed  that  allows 
a  user's  behavior  to  be  tracked  throughout  various  interactive  sessions  with 
the  system.  We  further  believe  that  both  novice  and  expert  users  should  be 
interviewed  and  data  collected  on  the  manner  in  which  a  wide  range  of  problems 
might  be  handled,  given  access  to  particular  data.  Moreover,  investigation 
and  evaluation  of  those  protocols  that  have  been  obtained  from  various  system 
users,  may  allow  selection  of  several  protocols  as  models  for  operating  the 
system  with  particular  outcomes  are  desired. 
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Given  the  above  Information,  It  Is  possible  to  structure  the  range  of 
user  problems  Into  categories  that  differ  with  regard  to  the  level  of 
difficulty  they  present  to  tie  them,  both  conceptually  and  In  the  actual 
software,  to  the  appropriate  models  of  user  problem  solving  that  we  have 
developed.  This  would  form  the  basis  for  an  "adaptive  training"  mode  of 
system  operation,  wherein  a  user  would  start  at  a  particular  level  of  system 
operation  (specific  to  the  task  he  had  to  perform)  and  would  attempt  to  solve 
the  problem.  If  the  user  failed  to  solve  the  problem  at  that  level,  the 
system  would  automatically  present  an  alternative  model  of  lesser  difficulty 
to  the  user,  training  the  user  throughout  the  session  to  a  level  of  acceptable 
performance  for  a  task  of  that  difficulty.  Once  the  user  has  mastered 
performance  for  that  level  of  difficulty  of  the  problem  (and  the  associated 
mode1)the  level  of  difficultly  would  Increase,  and  so  on.  The  result  of  this 
adaptive  training  would  be  to  adjust  the  training  parameters  to  the  user. 

SUWARY  OF  TRAINING  THE  USER 

System  documentation  will  be  used  for  the  training  of  users.  This 
documentation  will  be  three  dimensional,  consisting  of  software  specification, 
software  functional  description,  and  a  genuinely  useful  training  and  user's 
guide. 

Software  Specifications  and  Documentation.  Software  routines  and  sub¬ 
routines,  as  well  as  all  special -function  software  modules  will  be  detailed 
and  explained  In  a  software  specifications  document,  largely  before  any  of  the 
actual  code  Is  written.  This  will  be  reviewed  by  the  software  engineers 
(along  with  the  human  factors  engineers)  and  all  questions  as  to  system 
software  functions  and  training  issues  will  be  addressed  early  on  in  the 
process  of  writing  code. 

In  addition,  all  system  software  will  be  well -documented,  as  part  of  the 
coding  process.  This  refers  to  actually  writing  Into  the  code  (as  comment  or 
explanation  lines)  what  each  module  and  routine  of  the  software  is  designed  to 
do.  This  Is  critical  so  that  If,  for  any  reason,  the  original  software 
programmer  that  wrote  the  code  Is  unavailable,  another  programmer  will  be  able 
to  learn  the  code  and  the  entire  program,  and  make  whatever  additions  or 
modifications  to  the  code  are  necessary,  accurately  and  without  delay. 

Software  Functional  Description.  The  functional  description  of  the 
software  for  Product  Five  will  be  available  for  training  system  functional 
Issues. 

Training  and  User's  Guide.  The  Training  and  User's  guide  documentation 
will  be  used  during  training  sessions. 

This  user's  guide  will  be  one  that  follows  the  sequence  of  operations 
Inherent  In  the  system  Itself.  Therefore,  it  Is  advantageous  to  present  the 
Information  contained  in  the  user's  guide  In  a  well  structured,  well-indexed 
fashion  that  follows  the  general  procedures  of  the  system  itself.  Further, 
since  the  system  has  been  designed  with  regard  to  on-screen  Instructions, 
prompts,  error  messages  (that  Inform  the  user  not  only  what  error  was 
committed  but  what  he  must  do  to  correct  the  error),  the  user's  guide  is  a 
reference  that  the  user  may  access  when  he  requires  detailed  Information  on  a 
particular  function,  rather  than  a  "how  to  use  the  system"  tool.  Idealy,  the 
Product  Six  system  Is  one  whose  operation  is  largely  self  evident.  That  is, 
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the  user  of  this  properly  "human  factored"  system  will  be  able  to  "walk  Into" 
the  system,  guided  only  by  the  on-screen  Instructions  and  prompts  provided. 
Although  some  systems  are  of  such  complexity  that  a  manual  Is  indeed 
necessary,  the  approach  to  the  development  of  the  Product  Six  system  is  one 
wherein  on-screen  (dynamic)  Information  regarding  its  operation  has  been 
maximized,  and  static  (off-screen)  information  regarding  its  operation  has 
been  minimized. 


INSTITUTIONALIZATION 


ACCEPTANCE  AND  IMPLEMENTATION 

HPT  Product.  The  two  most  critical  aspects  of  this  ARI  project  are  an 
understanding  of  its  unique  importance  to  the  U.S.  Army,  and  the  necessity  of 
taking  the  proper  steps  to  ensure  that  the  Army  will  accept  and  implement  its 
results. 

In  many  previous  cases  of  advanced  weapon  system  development, 
insufficient  attention  has  been  paid  to  the  human  component  of  the  system  in 
the  early  conceptual  stages,  and  as  a  result  the  systems  have  encountered 
serious  problems  during  the  development  and  fielding  stages.  In  the  case  of 
the  MANPRINT  effort,  however,  this  does  not  appear  to  be  the  case.  Consider¬ 
able  attention  is  being  given  at  top  planning  levels  to  the  human  component 
and  to  the  means  available  for  integrating  MANPRINT  data  into  the  design  and 
development  of  new  and  complex  systems. 

System  Transfer.  In  an  article  in  Computer  Decisions  by  Martin  Lasden 
(1981),  a  passage  from  Machiavelll 's  The  Prince  is  cited  regarding  the  subject 
of  change: 

"There  is  nothing  more  difficult  to  arrange,  more  doubtful 
of  success,  and  more  dangerous  to  carry  through  than 
initiating  changes.  The  innovator  makes  enemies  of  those 
who  prospered  under  the  old  order,  and  only  lukewarm  support 
is  forthcoming  from  those  who  prosper  under  the  new.  Their 
support  is  lukewarm,  partly  because  men  are  generally 
incredulous,  never  really  trusting  new  things  unless  they 
have  tested  them  by  experience.  In  consequence,  whenever 
those  who  oppose  the  changes  can  do  so,  they  attack 
vigorously,  and  the  defense  made  by  the  others  is 
ineffective.  So,  both  the  innovator  and  his  friends  are 
endangered  together." 

This  brief  passage  might  very  well  summarize  the  perils  of  technology 
transfer.  But  if  we  study  the  passage  for  a  moment,  a  number  of  Ideas  emerge 
regarding  how  to  introduce  a  system  such  as  Product  Five  Into  the  "field". 

The  first  has  to  do  with  pacifying  "those  who  prosper  under  the  old 
[non-computer-based  system]  order."  Incentives  must  be  Implemented  that  will 
make  them  at  least  eager  to  experiment  with  the  new  system.  (Furthermore, 
since  the  system  has  been  designed  with  the  aid  of  a  solid  requirements 
analysis  they  will  not  have  to  restructure  what  they  do  to  use  the  system; 


E3-84 


Instead,  the  system  will  be  able  to  help  them  Improve  their  job  performance.) 
The  Incentives  must  be  explicitly  job  related,  and  bureaucratically 
sanctioned.  The  job  relatedness  criterion  has  been  satisfied  by  a  judiciously 
implemented  requirements  analysis.  If  a  requirements  analysis  Is  not  (or  Is 
badly)  performed,  there  will  be  a  perceived  and  real  disconnect  between  what 
the  system  and  target  user  do.  Under  these  circumstances,  some  users  will 
accept  computer-based  systems,  display  them  prominently  in  their  offices, 
seldom  actually  use  them,  and  then  eventually  transfer  out  of  their  office  on 
the  crest  of  a  reputation  for  innovativeness  and  vision. 

Another  solution  to  the  job-relatedness  problem  is  to  consider  the  newly 
developed  participatory  approach  to  computer  systems  design  (Mumford  and 
Henshall,  1979).  The  impetus  for  the  development  of  the  approach  has  been 
summed  up  nicely  by  one  Qulalty  of  Working  Life  Institute  consultant:  "no  one 

has  the  right  to  design  a  work  system  for  someone  else . the  role  of  the 

expert  should  be  to  help  the  worker  design  his  own  work  system"  (Lasden, 
1981). 

Finally,  the  transfer  strategy  should  involve  some  trial  field 
applications  before  the  final  version  is  released  and  distributed  en  masse  to 
prospective  users  (If  that  is  the  plan).  This  will  provide  some  valuable  user 
feedback  to  the  designers  so  that  they  can  make  any  necessary  adjustments. 

Implementation  of  Solution  Approach.  We  will  encounter  some  obstacles  in 
the  Implementation  of  the  solutions  outlined  above.  From  our  experience  with 
programs  of  this  type,  three  major  obstacles  are  virtually  certain.  One  is 
that  the  timing  of  major  technology  transfer  steps  is  frequently  critical,  and 
Is  usually  difficult  to  adjust  to  rapidly  if  these  steps  have  not  been 
anticipated.  Two  is  personnel  turbulence  within  the  military  structure,  so 
that  by  the  time  a  person  is  indoctrinated  in  the  importance  of  the  project, 
he  or  she  has  moved  on.  Three  Is  that  the  resources  necessary  to  effect 
transfer  are  usually  not  planned  for  when  the  R&D  project  is  staffed, 
scheduled,  and  funded,  so  that  they  can  not  be  afforded  when  they  are  needed. 

To  ensure  our  close  attention  to  these  important  issues  involved  in 
technology  transfer  —  including  the  identified  problems,  implementation 
strategies,  and  obstacles  —  we  will  address  problems  of  technology  transfer 
by  adopting  a  discipline  of  transfer  planning  and  implementation  previously 
found  to  be  successful  in  numerous  efforts.  This  task  will  feature  early  and 
continuing  user  participation  in  the  program  to  guarantee  the  support  of  the 
ultimate  beneficiaries  of  the  Product  Five  concept,  it  will  insure  that 
project  resources  are  there  when  they  are  needed,  and  it  will  promote  the  long 
term  persistence,  which  is  necessary  if  the  transfer  plan  is  to  be 
successfully  executed. 
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